Difference between revisions of "Talk:NFS"
(→Restarting rpc-idmapd and rpc-mountd: forgot signing) |
(→Add "enable rpc-statd.service" in the Mounting From Linux Section: new section) |
||
| (10 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
| − | == | + | I think that {{ic|/etc/systemd/system/auto_share.service}} should contain the following line after {{ic|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 {{ic|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 {{ic|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 {{ic|systemd}}. | ||
| − | |||
| − | + | {{ic|/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 {{ic|/lib/systemd/system/auto_share.service}} and re-enabling it using the command | |
| − | : | + | # systemctl reenable auto_share.service |
| + | |||
| + | --[[User:Blippy|Blippy]] ([[User talk: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? | ||
| + | [[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.serviceand 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
Suggested: