|(14 intermediate revisions by 6 users not shown)|
exportfs- error== |+|
|−|I applied this article to my server today and I found an exportfs- error: in /etc/exports a range of clients has to be described like 'ip/netmask'. CORRECT WAY: '192.168.0.0/255.255.255. 0', whereas the example on this page throws an error.--[[User:Zenlord|Zenlord]] 08:34, 30 September 2009 ( EDT) |+|
this to and an -to be . . , the on ()
| || |
|−|==SSH tunnelling== |+|
|−|Since NFSv4 is a insecure protocol (doesn't encrypt traffic), what about adding some info about tunneling it with SSH? This link is very useful: http://blogs.sun.com/shepler/entry/tunneling_nfs_traffic_via_ssh |+|
|−|The only problem, rpcbind has to be also tunneled. |+|
is a , is be .
| || |
|−|==client ip address/ranges== | |
|−|Also mentioning that we need to put client ip address/ranges in the /etc/exports might be a good idea for people using NFS for the first time. [[User:Inxsible|Inxsible]] | |
| || |
|−|== Mounting the partitions on the client == |+|
the it the it -
|−|I tried following the wiki but it seems that, for the client, it is no longer necessary to start rpcbind or nfs- common services. --[[User:Angheloko|Angheloko]] 11:44, 8 October 2011 (EDT) |+|
| || |
|−|== Unmounting non- api filesystems hangs == |+|
| || |
|−|I've figured out that if you don't add netfs to daemons in /etc/ rc. conf (because you mount nfs shares manually) shutting down will hang with " Unmounting non-api filesystems". Adding netfs to daemons fixes that. |+|
/etc/.with "" .
| || |
|−|Maybe that should be added to the troubleshooting section? |+|
should the ?
| || |
|−|I would be happy to add it. A bit of googling indicates that I' m not the first one who's had that problem. |+|
I think that
/etc/systemd/system/auto_share.service should contain the following line after
The rationale for this is that you need to wait for the network to be up and running before attempting an NFS connect from client-side. You also need to perform the NFS mountings before making user sessions available, because the latter may be dependent on the former. For example, my bash profile is stored on a remote server, so I need NFS drives mounted before I even attempt a login. On some systems, maybe the whole
home directory is on a different computer (as would be the case for thin clients), meaning that they should definitely be mounted before users can log in.
You need to enable
NetworkManager-wait-online.service like so:
# systemctl enable NetworkManager-wait-online
I can't help thinking that this is a bit of a kludge in any event, and is a scenario that should be handled automatically by
/etc/systemd/system/auto_share.service is a bad place to create the file. Instead, do it in the standard way by creating it as
/lib/systemd/system/auto_share.service and re-enabling it using the command
# systemctl reenable auto_share.service
--Blippy (talk) 20:24, 8 September 2013 (UTC)
Make iptables.rules syntax more clear
For me the file /etc/iptables/iptables.rules didn't exist so I created it with the lines in Firewall configuration section. After that iptables failed to start, giving syntax errors. After some searching, I added "*nat" at top and "COMMIT" at bottom of the file, and it worked.
Will adding this info make it more clear or should we leave it way it is?
axper (talk) 18:48, 28 September 2013 (UTC)
If /etc/iptables/iptables.rules didn't exist then you didn't use a firewall and there was no need to do any configuration to enable NFS access through a firewall. I don't think we should add too much information about how to configure a firewall in general on the NFS page.
I checked the ssh page to see how they address firewalls (ssh was the first thing I could think of that probably needs some firewall configuration) and they use command like
# iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT
instead of editing iptables.rules.
Should we change the article to show commands similar to above rather than talking about /etc/iptables/iptables.rules or should we just keep the one sentence mentioning the port numbers and protocols?
Crawlman (talk) 07:24, 18 December 2013 (UTC)
Add "enable rpc-statd.service" in the Mounting From Linux Section
Ensure that rpc.statd, the daemon that listens for reboot notifications from other hosts, is running on the client. If not, start it with:
# systemctl start rpc-statd.service
and for future reboots, enable it with:
# systemctl enable rpc-statd.service
This avoids the error message:
mount.nfs: rpc.statd is not running but is required for remote locking.
mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
mount.nfs: an incorrect mount option was specified
Add a new note below
Note: Server name needs to be a valid hostname (not just IP address). Otherwise mounting of remote share will hang.
Note: Not all servers run the same NFS package. For example, Debian Squeeze will reject
mount -t nfs4, but it accepts
mount -t nfs. Check
man mount for the full list of options.
Maxb (talk) 20:04, 6 February 2014 (UTC)