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
Suggest configuration edits
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.
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?