Talk:NFS

From ArchWiki

Are the following services still valid and what do they do?

The following services seem to be provided by nfs-utils: nfs-idmapd.service, nfs-mountd.service and nfs-utils.service. Can someone please provide details why these services are shipped and their usage?

Thanks.

Francoism (talk) 19:05, 10 June 2018 (UTC)Reply[reply]

You can take a look at nfs.systemd(7)
These systemd units are not needed for NFSv4-only servers:
nfs-server.service
rpcbind.service
rpcbind.socket
rpc-svcgssd.service
nfs-mountd.service
rpc-statd.service
rpc-statd-notify.service
rpc-gssd.service

Arash (talk) 11:54, 28 November 2023 (UTC)Reply[reply]

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)Reply[reply]

ARM mount options 1

<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)Reply[reply]

=== 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)Reply[reply]
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)Reply[reply]

<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)Reply[reply]

ARM mount options 2

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)Reply[reply]

<snip>

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

<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)Reply[reply]

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

Graysky (talk) 21:12, 4 March 2015 (UTC)Reply[reply]

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)Reply[reply]

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)Reply[reply]

I have removed the note, since there have been some changes since version 2.x.x. Can anyone confirm if the issue is still there? Lonaowna (talk) 11:25, 17 March 2017 (UTC)Reply[reply]

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?

—This unsigned comment is by Lacrymology (talk) 2015-10-08. Please sign your posts with ~~~~!

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?

—This unsigned comment is by MountainX (talk) 2016-06-25. Please sign your posts with ~~~~!

Mount using /etc/fstab with systemd

Is there a reason to have timeo=14 when using x-systemd.automount? At one time the man page showed a sample fstab entry using timeo=14, but it wasn't relevant to anything. I can't seem to find any reason why it is beneficial for this purpose as indicated on the wiki.

servername:/home   /mountpoint/on/client  nfs  _netdev,noauto,x-systemd.automount,x-systemd.mount-timeout=10,timeo=14,x-systemd.idle-timeout=1min 0 0

Matthew02 (talk) 02:53, 15 February 2020 (UTC)Reply[reply]

I also tried to find out what timeo is for. According to the nfs-manpage, changing the default timeo value really just seems relevant if you use nfs over TCP, because the default timeout would be 60s, increasing to 600s. For UDP, the default would be 1.1 s, the examples increases this to 1.4 s, and timeo is only used for "infrequent" request types (others than read and write). But, if for whatever reason, you use NFS over TCP, the example should reduce the time the system hangs in case of connection problems (from 60s to 1.4s for the first failed request). Maybe someone using NFS over TCP can test this ?
Strikemybread (talk) 07:22, 23 June 2020 (UTC)Reply[reply]

NFS Mounts on armv7h

This is just FYI because I'm sure the number of people this affects is very small, however my odroid plug stopped behaving with NFS a few months back. It would autofs, let's say /data/dir1 fine, but CDing into dir1 would yield an error that the directory does not exist. Mounting by hand gave me a protocol error, after much tweaking the NFS server and client, Arch configs, reinstalling, and about a zillion other things, off and on over the past few months, I finally tracked it back to LSM not knowing about AppArmor (after some combing through packet dumps). My solution was to append "security=apparmor" to the kernel boot. At least I think that's what fixed it. I do Linux sysadmining for a living (but not much Arch, love it for the Odroid, however). I think I covered my bases with NFS3 vs. NFS4, and various other things that can go wrong. At any rate, don't know if it merits a mention somewhere, but it was driving me nuts. :) I used a fairly generic Arm image from the website to bootstrap the plug.

NoSuchPerson (talk) 03:16, 19 February 2020 (UTC)Reply[reply]

Security of keeping a separate NFS root and using bind mounts

Quoting from the wiki:

The NFS server needs a list of exports (see exports(5) for details) which are defined in /etc/exports or /etc/exports.d/*.exports. These shares are relative to the so-called NFS root. A good security practice is to define a NFS root in a discrete directory tree which will keep users limited to that mount point. Bind mounts are used to link the share mount point to the actual directory elsewhere on the filesystem.

Are there any sources for this? Could someone elaborate more on why this approach is more secure than directly mounting the directories we want to publish without doing a bind mount?

—This unsigned comment is by Always Blue (talk) 14:19, 16 October 2021. Please sign your posts with ~~~~!

the auto_share script can unmount your main partitions

the sed command used in the auto_share script should not be used if you're a btrfs user. since it checks for a : somewhere in the line, it also catches btrfs entries which are using compress=zstd:3 for example. Something like this works for me

sed -n -e '/^[a-zA-Z0-9.-]*\(\.[a-zA-Z]\+\)\{0,1\}:/p' /etc/fstab

Hillbicks (talk) 11:13, 20 October 2023 (UTC)Reply[reply]

NFSv4-Only setup

I mask all systemd units related to NFSv3:

$ systemctl mask nfs-server.service rpcbind.service rpcbind.socket nfs-mountd.service rpc-statd.service rpc-statd-notify.service

And set ver3 and udp options to no in /etc/nfs.conf

[nfsd]
udp=n
#tcp=y
vers3=n
#vers4=y
#vers4.0=y
#vers4.1=y
#vers4.2=y

Make my exports with all_squash option.

Then start/enable nfsv4-server systemd service.

Please NOTE that using /etc/sysconfig/nfs is deprecated. You have to use /etc/nfs.conf instead.
Arash (talk) 11:24, 28 November 2023 (UTC)Reply[reply]

What do you want to discuss here? — Lahwaacz (talk) 20:47, 28 November 2023 (UTC)Reply[reply]
It did work for me. But I'm not sure if it does for everyone and in any case. Also I don't have any good/enough reference to approve this method of setup.
So it's really not enough valid in my opinion to be on the main page without discussion and review of others.

Arash (talk) 21:27, 28 November 2023 (UTC)Reply[reply]

Verifying /etc/nfs.conf correctness

You can test correctness of your /etc/nfs.conf file using nfsconf(8) command.
Arash (talk) 11:33, 28 November 2023 (UTC)Reply[reply]

Parent exports options override child exports options

For example, a directory without rw option, exported as root (with fsid=0/root option) will make its child exports ReadOnly even if you provide rw option for them. [1]

Arash (talk) 17:35, 28 November 2023 (UTC)Reply[reply]

gvfs does not support NFSv4

gvfs and programs depending on it (like Nautilus) does not support NFSv4. And thus can't mount nfsv4 exports. [2][3]

Arash (talk) 17:46, 28 November 2023 (UTC)Reply[reply]

Should some where in main page mention that exFat don't support nfs?

source: [4] Heddxh (talk) 02:33, 12 February 2024 (UTC)Reply[reply]

It's definitely useful. The problem is that there's no information about filesystems NFS support in the article. So perhaps we assume that all/most filesystems support NFS, by default.

Perhaps, a note in NFS#Server configuration section is a good place, or just add it to the Notes that already exist in introduction.

Arash (talk) 03:40, 19 February 2024 (UTC)Reply[reply]
Has anyone found a link from the upstream/kernel documentation that lists the supported file systems? Heddxh (talk) 06:14, 20 February 2024 (UTC)Reply[reply]