Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have autofs installed on several linux servers that are connecting to central NFS server for the users /home directories. It works great when mounting the directories on login, but the mounts never seem to timeout. I've checked /etc/sysconfig/autofs and the default is indeed set to 300, so these should be timing out after 5 minutes.

Restarting autofs does umount all of the directories, so I know it's capable.

I've attempted using lsof randomly on the directories but no files appear open at any time.

I've also mounted a random directory that I know is not active, but these never umount themselves. Some of these boxes have 10+ users that have logged in once, and the mounts never drop.

I'm just trying to find out of there is a better method to finding out why. I don't see anything specific in any logs.

Any suggestions are appreciated. Thanks!


I turned on debugging for autofs but it doesn't seem to reveal anything out of the ordinary. These logs were generated 7 minutes after the /home/user1 was initially mounted and after 6 minutes of inactivity. According to the 5 minute default, this should have been unmounted. I never saw a log come through that indicated an attempt was even made to umount.

Jan 11 12:52:00 linux automount[26505]: st_expire: state 1 path /home
Jan 11 12:52:00 linux automount[26505]: expire_proc: exp_proc = 3055176592 path /home
Jan 11 12:52:00 linux automount[26505]: expire_proc_indirect: expire /home/user1
Jan 11 12:52:00 linux automount[26505]: expire_proc_indirect: expire /home/user2
Jan 11 12:52:00 linux automount[26505]: expire_proc_indirect: expire /home/user3
Jan 11 12:52:00 linux automount[26505]: 3 remaining in /home
Jan 11 12:52:00 linux automount[26505]: expire_cleanup: got thid 3055176592 path /home stat 7
Jan 11 12:52:00 linux automount[26505]: expire_cleanup: sigchld: exp 3055176592 finished, switching from 2 to 1
Jan 11 12:52:00 linux automount[26505]: st_ready: st_ready(): state = 2 path /home

Update 2 After talking to Red Hat support about this, the solution ended up being to just shorten the timeout value for home directories. I did that and looks well. Something apparently is traversing the mount point every 2 1/2 to 3 minutes and causing this to stay up.

The solution was to add the timeout value to the /etc/auto.master file for that mapping:

 /home     /etc/auto_home --timeout=120
share|improve this question
what command(s) are you using to determine that these mounts are present? I assume df, but just want to clarify. – Banjer Jan 11 '13 at 23:29
Yes, I'm using df to check for the mounted space. I just cd to the directories as root to get them to mount. – SteveHNH Jan 14 '13 at 13:20

Besides TIMEOUT variable autofs has a checking interval:

# cat /var/log/messages
Jan 11 21:45:35 client automount[24804]: mounted offset on /net/server/share with timeout 300, freq 75 seconds

It is equal to TIMEOUT/4. Every TIMEOUT/4 seconds autofs asks kernel when directory was accessed last time. So in your environment you have directory umnounted after 375 seconds of inactivity.

To get more detailed log you should add LOGGING="debug" to /etc/sysconfig/autofs

share|improve this answer
I see. Thanks for the clarification. The logs above continued well after the 6 minutes of inactivity, and exceeded 375 seconds. I keep thinking that something has to be accessing these directories, or the umount would be attempted. I guess my real objective is to find out what is accessing this directory, if anything. That can be the only reason I can think of that it wouldn't umount. – SteveHNH Jan 11 '13 at 18:13

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.