automount nfs: autofs timeout settings for unreliable servers – how to avoid hangup?

I’m running a small server for our flat share. It’s mostly a file server with some additional services. The clients are Linux machines (mostly Ubuntu, but some others Distros too) and some Mac(-Book)s in between (but they’re not important for the question). The server is running Ubuntu 11.10 (Oneiric Ocelot) ‘Server Edition’, the system from which I do my setup and testing runs the 11.10 ‘Desktop Edition’. We where running our shares with Samba (which we are more familiar with) for quite some time but then migrate to NFS (because we don’t have any Windows users in the LAN and want to try it out) and so far everything works fine.

Now I want to setup auto-mounting with autofs to smooth things up (up to now everyone mounts the shares manually when needed). The auto-mounting seems to work too. The problem is that our “server” don’t run 24/7 to save energy (if someone needs stuff from the server s/he powers it on and shuts it down afterwards, so it only runs a couple of hours each day). But since the autofs setup the clients hang up quit often when the server isn’t running.

• I can start all clients just fine, even when the server isn’t running.
• But when I want to display a directory (in terminal or nautilus), that contains symbolic links to a share under /nfs while the server isn’t running, it hangs for at least two minutes (because autofs can’t connect to the server but keeps trying, I assume).
  • Is there a way to avoid that? So that the mounting would be delayed untill a change into the directory or till content of that directory is accessed? Not when “looking” at a link to a share under /nfs? I think not, but maybe it is possible not to try to access it for so long? And just give me an empty directory or a “can’t find / connect to that dir” or something like that.
• When the server is running, everything works fine.
• But when the server gets shut down, before a share got unmounted, tools (like df or ll) hang (assuming because they think the share is still on but the server won’t respond anymore).
  • Is there a way to unmount shares automatically, when the connection gets lost?
• Also the clients won’t shutdown or restart when the server is down and they have still shares mounted. They hang (infinitely as it seems) in “killing remaining processes” and nothing seems to happen.

I think it all comes down to neat timeout values for mounting and unmounting. And maybe to remove all shares when the connection to the server gets lost.

So my question is: How to handle this? And as a bonus: is there a good way to link inside /nfs without the need to mount the real shares (an autofs option or maybe using a pseudo FS for /nfs which gets replaced when the mount happens or something like that)?

My Setup

The NFS setting is pretty basic but served us well so far (using NFSv4):

/etc/default/nfs-common

NEED_STATD=
STATDOPTS=
NEED_IDMAPD=YES
NEED_GSSD=

/etc/idmapd.conf

[General]
Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = localdomain
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup

/etc/exports

/srv/   192.168.0.0/24(rw,no_root_squash,no_subtree_check,crossmnt,fsid=0)

Under the export root /srv we got two directories with bind:

/etc/fstab (Server)

...
/shared/shared/      /srv/shared/      none    bind  0 0
/home/Upload/        /srv/upload/      none    bind  0 0

The 1st one is mostly read only (but I enforce that through file attributes and ownership instead of NFS settings) and the 2nd is rw for all. Note: They have no extra entries in /etc/exports, mounting them separately works though.

On the client side they get setup in /etc/fstab and mounted manually as needed (morton is the name of the server and it resolves fine).

/etc/fstab (Client)

morton:/shared  /nfs/shared nfs4    noauto,users,noatime,soft,intr,rsize=8192,wsize=8192    0   0
morton:/upload  /nfs/upload nfs4    noauto,users,noatime,soft,intr,rsize=8192,wsize=8192    0   0

For the autofs setup I removed the entries from /etc/fstab on the clients and set the rest up like this:

/etc/auto.master

/nfs    /etc/auto.nfs

First I tied the supplied executable /etc/auto.net (you can take a look at it here) but it won’t automatically mount anything for me. Then I write a /etc/auto.nfs based on some HowTos I found online:

/etc/auto.nfs

shared  -fstype=nfs4  morton:/shared
upload  -fstype=nfs4  morton:/upload

And it kinda works… Or would work if the server would run 24/7. So we get the hangups when a client boots without the server running or when the server goes down while shares where still connected.

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

Mount the NFS-share on the clients using the mount-options “bg,intr,hard”.

Most important in your case is “bg” for background – which tells the system not to block when the server is not available.

“intr” for interrruptable – so you can kill hanging mounts on the client with the kill command.

“hard” is the opposite of “soft”. The difference is that “hard” will keep trying endlessly while “soft” will exponentially back off its retries when the server is not available.

Method 2

I played around some more with some of the options from the man page. All of bg,hard, bg,soft, fg,hard and fg,soft give me return times of over two minuets.

Setting retrans=1,retry=0 (combined with any of the above) though, gives me times around three seconds. Pretty decent. Although I’m not quiet sure what each combination means. Will dig around further.

Also I came across the autofs options MOUNT_WAIT and UMOUNT_WAIT. I haven’t been able to get some differnt results with them but I will keep trying. Seems lika a good way to use “more secure” (aka more retries, etc.) NFS option but quick return times for autofs, or not?

Method 3

Using any mount system, you want to avoid situations where Nautilus lists the directory containing a mount that may or not be mounted. So, with autofs, don’t create mounts in, for instance, /nfs. If you do, when you use Nautilus to list the ‘File System’ it will try to create whatever mounts should exist in /nfs, and if those mount attempts fail it takes minutes to give up.

So what I did was change auto.master to create the mounts in /nfs/mnt.

This fixed the problem for me. I only get a long delay if I try to list the contents of /nfs/mnt, which I can easily avoid.

Method 4

To set up an NFS file system to mount automatically each time you start your Red Hat Linux system, you need to add an entry for that NFS file system to the /etc/fstab file. The /etc/fstab file contains information about all different kinds of mounted (and available to be mounted) file systems for your Red Hat Linux system.
EX: : nfs
The corresponds to hostname, IP address, or fully qualified domain name of the server exporting the file system.
The is the path to the exported directory.
The specifies where on the local file system to mount the exported directory. This mount point must exist before /etc/fstab is read or the mount will fail
The area specifies mount options for the file system. For example, if the options area states rw,suid, the exported file system will be mounted read-write and the user and groupid set by the server will be used. Note that parentheses are not to be used here

All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0