Arch Linux

MatterCloud

Member

Registered: 2014-02-07

Posts: 10

[SOLVED] Unable to mount NFS shares at boot

Hi all,

I just switched to Arch from CrunchBang and everything is running beautifully, except that I can't get my NFS shares to mount at boot time.  The server runs Ubuntu Server with the same basic setup for years and I've never had a problem.  I initially used the same /etc/fstab entry I've always used, but the shares didn't mount.  Here's what I've tried:

I followed the NFS Wiki page and used the /etc/fstab entry recommended there.  My version looks like this:
192.168.1.2:/export /media/nfs nfs rsize=8192,wsize=8192,timeo=14,intr,_netdev 0 0
When I reboot, the shares aren't mounted.  (I've switched back and forth between nfs and nfs4 here without success; see below.)

As per the Wiki page, I confirmed that running 'showmount -e 192.168.1.2' sees and reports the shares. 

I tried a manual mount with 'mount -t nfs4 192.168.1.2:/export /media/nfs' and it complained: "mount.nfs4: mounting 192.168.1.2:/export failed, reason given by server: No such file or directory".  Changing 'nfs4' to 'nfs' in the above command gives the following errors:

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

So I tried using the '-o nolock' option and that worked, so I could at least access the files.  I changed "NEED_STATD" value in /etc/conf.d/nfs-common.conf to YES, as recommended on the NFS troubleshooting page, but the problem persisted. 

I then went to the forums and found this thread, which is exactly my problem and the author had tried all the things I tried.  The last post of that thread says that you need to start rpcbind before trying to mount.  I did that and a manual mount and it worked without errors.  So I enabled rpcbind, rebooted, and thought that would be the end of it.  But the shares still don't mount.  Upon reboot, I can run 'sudo mount -a' and it works without errors.  This suggests to me that it's not my /etc/fstab entry that's the problem.  I just don't know what else to try.  Of course, it's not a huge deal to run 'sudo mount -a' manually (which is what I've been doing), but I'd just like to know why it doesn't work.

Anyone have any ideas?  Maybe there are logs I can check?  I've never really done much with logs, so I don't even know where to start. 

Thanks in advance!

Last edited by MatterCloud (2014-02-08 19:39:28)

hezekiah

Member

From: US-East

Registered: 2014-02-08

Posts: 6

Re: [SOLVED] Unable to mount NFS shares at boot

Are you sure your network is available at the time that the NFS mounts are attempted? I presume you're using systemd? This is unfortunately fairly common with NFS fstab mounts and systemd.

If it's as I suspect and your network is not available at the time systemd goes to mount your NFS shares, the following information may help.

There's a number of recommendations across the various threads that I've seen on how to address the issue. As such, it seems to come down to personal preference.

There's good suggestions in Mounting NFS Not Working At Boot
There's also good advice in NFS Automatic Mount Handling

Notable suggestions for your perusal:
1. Utilize a systemd unit file to mount your NFS shares with dependencies specified on your network and rpc.statd
2. Utilize autofs or systemd automount facilities (see systemd.automount(5)) to mount the shares when you need them (and, presumably, after your network is fully functional)
3. Use NetworkManager dispatcher to execute a script that mounts the NFS shares when your network comes up
4. And of course, parting ways with systemd to return to sysvinit.

Hope this helps or at least gets you headed in the right direction.

MatterCloud

Member

Registered: 2014-02-07

Posts: 10

Re: [SOLVED] Unable to mount NFS shares at boot

Hi hezekiah,

Thanks for your reply.  You are quite correct.  I am using systemd and it was trying to mount the shares before the network was available.  I tried solutions 1 and 3 on your list.  I couldn't get the systemd unit file approach to work, but the NetworkManager dispatcher is working nicely.  It mounts the shares properly at boot and lets the system boot normally when the server is unavailable.  That's all I need!

Thanks for your help! 

I'll change this to [Solved]

WonderWoofy

Member

From: Los Gatos, CA

Registered: 2012-05-19

Posts: 8,414

Re: [SOLVED] Unable to mount NFS shares at boot

If the mounts are not necessary for the boot process itself, you don't have to use the NetworkManager tools to do this.  All you have to do is use the systemd.automount functionality.  Just add 'noauto,x-systemd.automount' to the mount options in your fstab.  Doing this will make it so that these shares will not be mounted until they are first accessed.

MatterCloud

Member

Registered: 2014-02-07

Posts: 10

Re: [SOLVED] Unable to mount NFS shares at boot

Hi WonderWoofy.  Thanks for your reply.

Just add 'noauto,x-systemd.automount' to the mount options in your fstab.  Doing this will make it so that these shares will not be mounted until they are first accessed.

I tried this just out of curiosity.  When I reboot and open the file manager (Thunar in this case), I find the shares are mounted and listed under 'Devices'--no access required.  That's fine, since it's the behaviour I want.  When I try it with the server machine offline, however, Thunar hangs and won't display anything.  I probably should have mentioned that I'm running from a laptop, so it's critical that whatever solution I use will also work when I'm outside my LAN.  I'd guess that systemd.automount can be configured to work for this, but since NetworkManager already works, I don't know why I'd bother.  Is there some reason I should prefer one method over the other? 

Thanks!

(Edited for grammar.  Yes, I'm that kind of nerd.)

Last edited by MatterCloud (2014-02-08 21:46:10)

hezekiah

Member

From: US-East

Registered: 2014-02-08

Posts: 6

Re: [SOLVED] Unable to mount NFS shares at boot

You're entirely welcome, MatterCloud. Glad one of those approaches was satisfactory.