Difference between revisions of "Talk:NFS"

From ArchWiki
Jump to: navigation, search
(Restarting rpc-idmapd and rpc-mountd: close.)
(NFS client section confusion)
 
(79 intermediate revisions by 21 users not shown)
Line 1: Line 1:
== Update and streamlined ==
+
== NetworkManager-wait-online ==
Took a stab at making the article lean and mean.  Cleaned-up, trimmed away fat, initscripts, etc.  Someone please edit the autofs section and make it systemd relevant.  I do not use this or I would do it myself.
+
  
[[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 21:00, 16 October 2012 (UTC)
+
I think that {{ic|/etc/systemd/system/auto_share.service}} should contain the following line after {{ic|Description}}:
  
== <s> Restarting rpc-idmapd and rpc-mountd </s> ==
+
After=NetworkManager-wait-online.service
 +
Before=systemd-user-sessions.service
  
When making changes to /etc/exports, I use systemctl to restart rpc-idmapd and rpc-mountd, but the changes do not take effect. I noticed that rpc-idmapd and rpc-mountd start other units. Its a pain going through and stopping each one individually. How do you shutdown or restart everything at once to reload exports? [[User:Axanon|Axanon]] ([[User talk:Axanon|talk]]) 19:09, 28 December 2012 (UTC)
+
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.
: I've learned a full server restart is ''not'' required to apply changes to a modified {{ic|/etc/exports}}. {{ic|# exportfs -ra}} will do this.[[User:Axanon|Axanon]] ([[User talk:Axanon|talk]]) 19:49, 30 December 2012 (UTC)
+
 
:: Thanks for updating the page. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 01:45, 1 January 2013 (UTC)
+
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)
 +
 
 +
== Suggest configuration edits ==
 +
 
 +
<snip>
 +
 
 +
3. Courtesy this recent thread:
 +
 
 +
[http://www.gossamer-threads.com/lists/gentoo/user/297428?page=last New default behavior in nfs-utils (1.3.2-r1)]
 +
 
 +
and in particular this comment:
 +
 
 +
[http://www.gossamer-threads.com/lists/gentoo/user/297452#297452 explanation by Neil Bothwick]
 +
 
 +
<code>
 +
The problem is that the mount command fails however you run it, from
 +
either init system or from a shell. It fails with "invalid mount options"
 +
because it now defaults to NFS V4.2 even if it is not enabled in
 +
the kernel. You need to either enable 4.2 or specifically set nfsver=4 to
 +
work around this.
 +
</code>
 +
 
 +
Put differently, for '''''[[ARM]]''''' nfs-utils 1.3.2-4 and later this fails:
 +
 
 +
<code>
 +
sudo mount -v server:/music /mntpoint
 +
</code>
 +
 
 +
with the all-purpose error message:
 +
 
 +
<code>
 +
mount.nfs: an incorrect mount option was specified
 +
</code>
 +
 
 +
while this:
 +
 
 +
<code>
 +
sudo mount.nfs4 -v -o nfsvers=4 server:/music /mntpoint
 +
</code>
 +
 
 +
works.
 +
 
 +
<snip>
 +
 
 +
[[User:Jhsnyder|Jhsnyder]] ([[User talk:Jhsnyder|talk]]) 22:54, 24 February 2015 (UTC)
 +
 
 +
::=== Points 1 and 2 ===
 +
::Good points, edited.  I used the systemd syntax recommended.  You can make the edits I think for the v4.2 stuff.
 +
::[[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 23:44, 24 February 2015 (UTC)
 +
 
 +
:::Will do. The change affects the fstab entry as well, so I should craft an fstab entry and verify it before editing the wiki page. I'm busy for the next couple of days, so not until the weekend.
 +
:::[[User:Jhsnyder|Jhsnyder]] ([[User talk:Jhsnyder|talk]]) 17:05, 25 February 2015 (UTC)
 +
 
 +
<snip>
 +
 
 +
... the following fstab entry enables automounts on an '''''[[ARM]]''''' client running nfs-utils 1.3.2-4 and later:
 +
 
 +
<code>
 +
server:/music  /MOUNT/POINT  nfs4  nfsvers=4,users,noauto,x-systemd.automount,x-systemd.device-timeout=10,timeo=14,noatime 0 0
 +
</code>
 +
 
 +
I had to reboot to get the fstab entry to take.
 +
 
 +
<snip>
 +
 
 +
 
 +
--[[User:Jhsnyder|Jhsnyder]] ([[User talk:Jhsnyder|talk]]) 13:50, 3 March 2015 (UTC)
 +
 
 +
== Jhsnyder edits ==
 +
 
 +
Did you write your recent edits based on an Arch ARM box?  See this thread where an Arch user failed to get mounts working with your new advice.  Am I OK reverting your edits?  I cannot get them to work on my x86_64 boxes either.
 +
 
 +
https://bbs.archlinux.org/viewtopic.php?id=194400
 +
 
 +
[[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 00:42, 4 March 2015 (UTC)
 +
 
 +
<snip>
 +
 
 +
(Forgot the sig)
 +
--[[User:Jhsnyder|Jhsnyder]] ([[User talk:Jhsnyder|talk]]) 14:36, 4 March 2015 (UTC)
 +
 
 +
<snip>
 +
________________________
 +
 
 +
One odd point: I can't reproduce the error you and the user saw. I set up five NFS clients and two NFS servers (one x86_64, one ARM), and they all Just Work with -t nfs4 and -o nfsvers=4 (once I corrected the stale IP in /etc/hosts).
 +
 
 +
But if x86_64 works without -t nfs4 and -o nfsvers=4, well ... who cares? Just use -t nfs.
 +
 
 +
--[[User:Jhsnyder|Jhsnyder]] ([[User talk:Jhsnyder|talk]]) 16:20, 4 March 2015 (UTC)
 +
 
 +
: Go ahead and revert your edits.  Thanks for clearing it up.
 +
[[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 21:12, 4 March 2015 (UTC)
 +
 
 +
Done.
 +
 
 +
Under "Mount using /etc/fstab", shouldn't the fstab entry be "nfs" rather than "nfs4"? I don't think that's one of my edits.
 +
 
 +
I deleted most of the text, just leaving recipes on the discussion page should an ARM user come looking for patches.
 +
 
 +
(Re-editing to add sig) --[[User:Jhsnyder|Jhsnyder]] ([[User talk:Jhsnyder|talk]]) 01:14, 5 March 2015 (UTC)
 +
 
 +
: Thanks, I moved the general note up to the top of the page and removed the replicates in the article. [[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 08:07, 5 March 2015 (UTC)
 +
 
 +
== Bad config file for server? ==
 +
From https://wiki.archlinux.org/index.php/NFS#Starting_the_server I edited /etc/conf.d/nfs-server.conf to disable v2 and v3, but that didn't seem to work. Looking at the service file, I noticed this:
 +
 
 +
    [Service]
 +
    EnvironmentFile=-/run/sysconfig/nfs-utils
 +
 +
    Type=oneshot
 +
    RemainAfterExit=yes
 +
    ExecStartPre=/usr/sbin/exportfs -r
 +
    ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS
 +
 
 +
So I added the options in $RPCNFSDARGS in /run/sysconfig/nfs-utils instead and that worked as expected. Did I do something wrong, or should we update the wiki?
 +
 
 +
== Client section confusion ==
 +
 
 +
The client section states: "Start '''rpcbind.service''' ... and enable...". However, the server section states that rpcbind.service is only required for older (V2, V3) NFS versions. See ''Starting the server'': The rpcbind.service is ... needed for older V2 and V3 exports.
 +
 
 +
Question: Is rcpbind.service still required on the client? For all NFS versions? Only for older versions?

Latest revision as of 20:03, 25 June 2016

NetworkManager-wait-online

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)

Suggest configuration edits

<snip>

3. Courtesy this recent thread:

New default behavior in nfs-utils (1.3.2-r1)

and in particular this comment:

explanation by Neil Bothwick

The problem is that the mount command fails however you run it, from either init system or from a shell. It fails with "invalid mount options" because it now defaults to NFS V4.2 even if it is not enabled in the kernel. You need to either enable 4.2 or specifically set nfsver=4 to work around this.

Put differently, for ARM nfs-utils 1.3.2-4 and later this fails:

sudo mount -v server:/music /mntpoint

with the all-purpose error message:

mount.nfs: an incorrect mount option was specified

while this:

sudo mount.nfs4 -v -o nfsvers=4 server:/music /mntpoint

works.

<snip>

Jhsnyder (talk) 22:54, 24 February 2015 (UTC)

=== Points 1 and 2 ===
Good points, edited. I used the systemd syntax recommended. You can make the edits I think for the v4.2 stuff.
Graysky (talk) 23:44, 24 February 2015 (UTC)
Will do. The change affects the fstab entry as well, so I should craft an fstab entry and verify it before editing the wiki page. I'm busy for the next couple of days, so not until the weekend.
Jhsnyder (talk) 17:05, 25 February 2015 (UTC)

<snip>

... the following fstab entry enables automounts on an ARM client running nfs-utils 1.3.2-4 and later:

server:/music /MOUNT/POINT nfs4 nfsvers=4,users,noauto,x-systemd.automount,x-systemd.device-timeout=10,timeo=14,noatime 0 0

I had to reboot to get the fstab entry to take.

<snip>


--Jhsnyder (talk) 13:50, 3 March 2015 (UTC)

Jhsnyder edits

Did you write your recent edits based on an Arch ARM box? See this thread where an Arch user failed to get mounts working with your new advice. Am I OK reverting your edits? I cannot get them to work on my x86_64 boxes either.

https://bbs.archlinux.org/viewtopic.php?id=194400

Graysky (talk) 00:42, 4 March 2015 (UTC)

<snip>

(Forgot the sig) --Jhsnyder (talk) 14:36, 4 March 2015 (UTC)

<snip> ________________________

One odd point: I can't reproduce the error you and the user saw. I set up five NFS clients and two NFS servers (one x86_64, one ARM), and they all Just Work with -t nfs4 and -o nfsvers=4 (once I corrected the stale IP in /etc/hosts).

But if x86_64 works without -t nfs4 and -o nfsvers=4, well ... who cares? Just use -t nfs.

--Jhsnyder (talk) 16:20, 4 March 2015 (UTC)

Go ahead and revert your edits. Thanks for clearing it up.

Graysky (talk) 21:12, 4 March 2015 (UTC)

Done.

Under "Mount using /etc/fstab", shouldn't the fstab entry be "nfs" rather than "nfs4"? I don't think that's one of my edits.

I deleted most of the text, just leaving recipes on the discussion page should an ARM user come looking for patches.

(Re-editing to add sig) --Jhsnyder (talk) 01:14, 5 March 2015 (UTC)

Thanks, I moved the general note up to the top of the page and removed the replicates in the article. Graysky (talk) 08:07, 5 March 2015 (UTC)

Bad config file for server?

From https://wiki.archlinux.org/index.php/NFS#Starting_the_server I edited /etc/conf.d/nfs-server.conf to disable v2 and v3, but that didn't seem to work. Looking at the service file, I noticed this:

   [Service] 
   EnvironmentFile=-/run/sysconfig/nfs-utils 

   Type=oneshot 
   RemainAfterExit=yes 
   ExecStartPre=/usr/sbin/exportfs -r 
   ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS

So I added the options in $RPCNFSDARGS in /run/sysconfig/nfs-utils instead and that worked as expected. Did I do something wrong, or should we update the wiki?

Client section confusion

The client section states: "Start rpcbind.service ... and enable...". However, the server section states that rpcbind.service is only required for older (V2, V3) NFS versions. See Starting the server: The rpcbind.service is ... needed for older V2 and V3 exports.

Question: Is rcpbind.service still required on the client? For all NFS versions? Only for older versions?