Based on advise I received in one of the LinuxQuestions forums a while back I configured autofs on my CentOS 6 workstation in place of a couple of scripts to mount and unmount 5 nfs exported directories on my server. The autofs process seems to work reasonably well with three exceptions. Here are my configuration files:

/etc/auto.master and /etc/auto.miscThe first issue... If I open /t10 on the workstation in Nautilus or gnome-commander it appears to be empty. The nfs mount points do not show up until I access them in some other manner such as cd/t10/data0 in a terminal - this will cause data0 to display or I can click on a bookmark in Nautilus to one of the nfs mount points or invoke a program which contains a link to one of the mount points.

And the second issue... when the server is shut down - its normal state as I use it basically for backup storage - I find a long delay when I click on a location launcher which opens a directory on the workstation (unrelated to any of the nfs locations) in Nautilus. The delay is only 2 - 3 seconds but as the response is normally just about instantaneous it seems like a long time.

Finally, and I just discovered this, if I have accessed the nfs locations in Nautilus and I then close Nautilus and shut down the server - Nautilus will not run again for about 30 - 40 seconds. It starts to launch and then dies. I kept trying and it eventually runs again.

Any advise appreciated.

TIA,

Ken

p.s. Is the "+auto.master" in auto.master correct? or should it be +auto.misc? I have no idea why that is in the config file. I must have copied it from some examples I had seen or perhaps it was in the default file when I installed autofs.

I've never understood why the sample auto.master contains that "+auto.master" line: '+' is used to include another file, and why would you ever include auto.master in itself? I removed it from my auto.master and have had no ill effects.

If you want the mountpoints to show up even when they're not in use then you want to use a 'direct map' rather than the 'indirect map' you're currently using. i.e.

/etc/auto.master:
/etc/auto.t10:
Don't use auto.misc for /t10, give it its own file as above, and leave auto.misc to handle things mounted on /misc, it's tidier that way.


I can't offer any advice on the nautilus stuff as I'm pretty much a cli jockey, but hopefully that's given you somewhere to start.

Thanks GazL,

That seems to help on a couple of fronts. I have a launcher to open the subdirectory where I keep my LibreOffice files and another on to a bunch of scripts. Both now open with lightning like speed - as they did before I setup autofs. If I click on /t10 in Nautilus I see the 5 mount points and I can open them with no delay or protest from Nautilus. They are of course empty when the server is off-line. They also show up in gnome-commander and I can enter the subdirectories without gnome-commander going off into space.

I just brought up the server and the mount points appear populated in Nautilus and gnome-commander as well Problem solved.

Thanks again,

Ken

Well I spoke (posted) too soon. While the speed of opening folders issue is resolved, AFTER connecting to the server and then shutting down the server gnome goes totally to crap. Folders (not associated with the nfs mounts) will not open AT ALL. gedit will not launch, other things freeze up etc. I did a shutdown/restart and rather than perform this evolution the system simply logged me out. I know that because I did not observer the machine rebooting. This seemed to clear some things up but still not a satisfactory solution.

I would note that before using autofs I had created the directory structure /t10/data0; /t10/data1 etc. so that the necessary directories were available to mount the remote nfs directories. Thinking that this might be causing conflict with autofs I remove the /t10 tree. If anything this made matters worse. The nfs mount points did appear when the server was up but when it was down gnome was hosed.

Bottom line I have canned autofs and gone back to my old mount and unmount scripts.

Ken