Difference between revisions of "Talk:NFS"

From ArchWiki
Jump to: navigation, search
(added new discussion about iptables.rules syntax)
(Add "enable rpc-statd.service" in the Mounting From Linux Section: new section)
(One intermediate revision by one other user not shown)
Line 18: Line 18:
 
Will adding this info make it more clear or should we leave it way it is?
 
Will adding this info make it more clear or should we leave it way it is?
 
[[User:Axper|axper]] ([[User talk:Axper|talk]]) 18:48, 28 September 2013 (UTC)
 
[[User:Axper|axper]] ([[User talk: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#Troubleshooting|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?
 +
[[User:Crawlman|Crawlman]] ([[User talk: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:
 +
{{bc|# systemctl start rpc-statd.service}} and for future reboots, enable it with:
 +
{{bc|# 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.}}
 +
Suggested:
 +
{{note|Not all servers run the same NFS package. For example, Debian Squeeze will reject {{ic|mount -t nfs4}}, but it accepts {{ic|mount -t nfs}}. Check {{ic|man mount}} for the full list of options.}}
 +
[[User:Maxb|Maxb]] ([[User talk:Maxb|talk]]) 20:04, 6 February 2014 (UTC)

Revision as of 20:04, 6 February 2014

I think that /etc/systemd/system/auto_share.service should contain the following line after Description:

After=NetworkManager-wait-online.service
Before=systemd-user-sessions.service

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 systemd.


/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.

Suggested:

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)