At the server, show the exported shares with
showmount -e
Also, check what is reported from the client end using 'showmount -e ’
showmount -e 192.168.19.101
Report back.
Do you mean you actually have directory /mnt/fs-home before you start automount on /mnt? I do not know what happens in this case. Normally if you use indirect mounts (like in your case) directory is expected to be empty. Or you should be configuring direct mounts.
# showmount -e
Export list for fs-OS421:
/media/databin 192.168.19.0/24
/media/torrents 192.168.19.0/24
/media/media 192.168.19.0/24
/media/software 192.168.19.0/24
/media/dyndata 192.168.19.0/24
/media/SG600 192.168.19.0/24
/home/geoff 192.168.19.0/24
# showmount -e 192.168.19.101
Export list for 192.168.19.101:
/media/databin 192.168.19.0/24
/media/torrents 192.168.19.0/24
/media/media 192.168.19.0/24
/media/software 192.168.19.0/24
/media/dyndata 192.168.19.0/24
/media/SG600 192.168.19.0/24
/home/geoff 192.168.19.0/24
No … nothing under /mnt … have tried to put it there but …ahah … but system won’t let me … for good reason so i have since learned! 
Before you start autofs, not after. Stop autofs and show “ls -l /mnt”.
no … not before either. I have manually set up the same mount points under /media to directly mount the NFS shares via fstab … and they work fine EXCEPT for when the laptop is on WiFi … the system hangs on boot looking for the fstab mounts as there is no network connection. Hence my interest in autofs.
out of frustration was about to rebuild the system from scratch … but thought first to STOP autofs and actually add a mount point myself … i know … bottom of the barrel stuff … but wanted to see what would happen after START autofs
First thing i notice on STOP is this:
**#** systemctl stop autofs
**#** systemctl status autofs
autofs.service - Automounts filesystems on demand
Loaded: loaded (/usr/lib/systemd/system/autofs.service; enabled)
Active: inactive (dead) since Mon 2016-01-04 19:00:10 AEDT; 5s ago
Docs: man:automount(8)
man:autofs(5)
Process: 2038 ExecStart=/usr/sbin/automount $AUTOFS_OPTIONS -p /var/run/automount.pid (code=exited, status=0/SUCCESS)
Main PID: 2040 (code=exited, status=0/SUCCESS)
Jan 04 19:00:09 akoya.home.gateway automount[2040]: **umount_autofs_indirect: ask umount returned busy /mnt**
Q: Does the final alert line throw any light???
so created the ‘mount point’ manually
**#** mkdir fs-home
**#** ls -l /mnt
total 0
dr-xr-xr-x 2 root root 0 Jan 4 19:06 **fs-home**
and START autofs
**#**systemctl start autofs
**#** systemctl status autofs
autofs.service - Automounts filesystems on demand
Loaded: loaded (/usr/lib/systemd/system/autofs.service; enabled)
Active: **active (running)** since Mon 2016-01-04 19:08:06 AEDT; 8s ago
Docs: man:automount(8)
man:autofs(5)
Process: 3321 ExecStart=/usr/sbin/automount $AUTOFS_OPTIONS -p /var/run/automount.pid (code=exited, status=0/SUCCESS)
Main PID: 3323 (automount)
CGroup: /system.slice/autofs.service
└─3323 /usr/sbin/automount -p /var/run/automount.pid
… and attempt to mount on demand by clicking on the Places link in Dolphin I get:
The file or folder /mnt/fs-home does not exist.
where clearly it does:
**#** ls -l /mnt
total 0
dr-xr-xr-x 2 root root 0 Jan 4 19:06 **fs-home**
Oh … and i forgot … all this after running UPGRADE from the installation disk !!
If nobody got any further thoughts i will bite the bullet and reinstall … but i would rather find out what i am doing wrong!!!
Thnx
So what happens in terminal “ls -l /mnt/fs-home/”?
I have no idea what Dolphin does, but I cannot reproduce it without it. Using your autofs configuration on Leap it works out of the box in terminal - I can list /mnt and it automounts indirect maps. Please show “cat /proc/mounts”.
**#** ls -l /mnt/fs-home/
ls: cannot access /mnt/fs-home/: No such file or director
**#** cat /proc/mounts
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
devtmpfs /dev devtmpfs rw,nosuid,size=1970116k,nr_inodes=492529,mode=755 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,nodev,mode=755 0 0
tmpfs /sys/fs/cgroup tmpfs rw,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-ag
ent,name=systemd 0 0
pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/net_cls,net_prio cgroup rw,nosuid,nodev,noexec,relatime,net_cls,net_prio 0 0
cgroup /sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event 0 0
cgroup /sys/fs/cgroup/hugetlb cgroup rw,nosuid,nodev,noexec,relatime,hugetlb 0 0
/dev/sda6 / ext4 rw,relatime,data=ordered 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=33,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,relatime 0 0
mqueue /dev/mqueue mqueue rw,relatime 0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
/dev/sda8 /media/locdata ext4 rw,relatime,data=ordered 0 0
/dev/sda7 /home ext4 rw,relatime,data=ordered 0 0
/etc/auto.nfs /mnt autofs rw,relatime,fd=6,pgrp=3323,timeout=10,minproto=5,maxproto=5,indirect 0 0
tracefs /sys/kernel/debug/tracing tracefs rw,relatime 0 0
gvfsd-fuse /run/user/1000/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=100 0 0
That would indicate it fails to mount. Any errors in logs (you can start journalctl -f in another terminal to see any errors). You can also enable automount debugging (add -d to AUTOFS_OPTIONS in /etc/sysconfig/autofs and restart aufofs) to see if it does anything.
/etc/auto.nfs /mnt autofs rw,relatime,fd=6,pgrp=3323,timeout=10,minproto=5,maxproto=5,indirect 0 0
autofs is active for /mnt. So for whatever reasons it fails to mount. Enable debugging and post logs produced when you try to access any subdirectory.
But first make sure /mnt is empty before you start autofs. “systemctl stop autofs”, make sure the line above is no more present in /proc/mounts, remove everything under /mnt, start autofs again.
It seems I’ve had exactly the same problem. With the proposed debug flag by arvidjaar, I got the error
lookup(program): lookup for FOLDER failed
when entering FOLDER. A quick search found the solution. My autofs setting files were executable, probably because I copied the files from a USB stick. Removing x flag solved my issue.
Maybe this is also the case here…
BINGO!!!
**#** ls -al /etc/auto.*
-rwxrwxrwx 1 root root 1292 Jan 3 20:21 /etc/auto.master
-rw-r--r-- 1 root root 524 Oct 1 19:42 /etc/auto.misc
-rwxr-xr-x 1 root root 1260 Oct 1 19:42 /etc/auto.net
-rwxr-xr-x 1 root root 614 Jan 3 20:23 /etc/auto.nfs
-rwxr-xr-x 1 root root 2191 Oct 1 19:42 /etc/auto.smb
**#** chmod /etc/auto.nfs -x
**#** ls -al /etc/auto.*
-rwxrwxrwx 1 root root 1292 Jan 3 20:21 /etc/auto.master
-rw-r--r-- 1 root root 524 Oct 1 19:42 /etc/auto.misc
-rwxr-xr-x 1 root root 1260 Oct 1 19:42 /etc/auto.net
-rw-r--r-- 1 root root 614 Jan 3 20:23 /etc/auto.nfs
-rwxr-xr-x 1 root root 2191 Oct 1 19:42 /etc/auto.smb
**#** ls /mnt/fs-home
**.ViberPC****.dbus****.gnome****.local** .profile .xsession-errors-:0 **Public**
.Xauthority .directory **.gnupg****.macromedia** .recently-used **Desktop****Templates**
**.adobe****.dropbox****.gstreamer-0.10****.moonchild productions****.sane****Documents****Videos**
.bash_history **.dropbox-dist** .gtkrc-2.0 **.mozilla****.thumbnails****Downloads****bin**
.bashrc .emacs .i18n **.nv** .xim.template **Dropbox****public_html**
**.cache** .esd_auth .inputrc .nvidia-settings-rc .xinitrc.template**Music**
**.config****.fonts****.kde4****.pki** .xsession-errors **Pictures **
THANK YOU!!!
lol!rotfl!
PS: I too had copied my auto.master and auto.nfs from archived copies … however, it was all working back then so i did not +x them!
Good to read of your success with this. I was about to suggest removing auto.master and auto.nfs and manually regenerating them, which would have achieved the same result (but without the realization that the wrong attributes were set in the first place). It’s not clear to me why they were set that way in the first place. Of course auto.net and auto.smb should be left as executable (as they contain scripts)
# ls -al /etc/auto.*
-rw-r--r-- 1 root root 836 Jan 3 23:10 /etc/auto.master
-rw-r--r-- 1 root root 524 Oct 1 22:42 /etc/auto.misc
-rwxr-xr-x 1 root root 1260 Oct 1 22:42 /etc/auto.net
-rw-r--r-- 1 root root 55 Jan 4 23:33 /etc/auto.nfs
-rwxr-xr-x 1 root root 2191 Oct 1 22:42 /etc/auto.smb
Yes indeed!! … thanks for you help deano … :shake::good:
If you “archived” them on a FAT or NTFS file system, that could explain what happened.