Are the following services still valid and what do they do?
The following services seem to be provided by
nfs-utils.service. Can someone please provide details why these services are shipped and their usage?
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
ARM mount options 1
3. Courtesy this recent thread:
and in particular this comment:
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
sudo mount.nfs4 -v -o nfsvers=4 server:/music /mntpoint
... 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.
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.
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.
- Go ahead and revert your edits. Thanks for clearing it up.
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.
- 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?
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
- 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)
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.
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?