16

I mount four servers (3 via cifs, 1 via sshfs) using autofs.

auto.master 

/- /etc/auto.all --timeout=60 --ghost

auto.all

/mnt \ /server1 -fstype=cifs,rw,credentials=/etc/.smbcredentials.txt,uid=1000,file_mode=0775,dir_mode=0775,users ://server1/ \ /server2/ -fstype=cifs,rw,credentials=/etc/.smbcredentials.txt,uid=1000,file_mode=0775,dir_mode=0775,users ://server2/ \ /server3 -fstype=cifs,rw,credentials=/etc/.smbcredentials.txt,uid=1000,file_mode=0775,dir_mode=0775,users ://server3/ \ /server4 -fstype=fuse,rw,allow_other,uid=1000,users,reconnect,cache=yes,kernel_cache,compression=no,large_read,Ciphers=arcfour :sshfs\#user@server\:/home

```

Everything is fine when I make a clean boot. I connect to my network (using a VPN) and autofs mounts everything.

Problem

When there is a network disconnect, e.g. when I hibernate my laptop or connect to a different network, autofs causes my explorer (dolphin) to freeze because it tries to load the remote share infinitely.

It becomes unresponsive and does not even react to SIGTERM commands. Sometimes I am lucky and calling sudo service autofs stop and sudo automount helps to resolve the issue. However, often it still stays freezed. Sometimes even, my whole dock freezes due to this making all applications unselectable. Then I have to make a full reboot..

I've searched for weeks now for solution how to deal with autofs in such situations. Before using autofs, I had everything mounted via /etc/fstab but that also required a manual remount after every network interruption.

I thought autofs would help me here but it causes me even more trouble.

Questions

  1. Is there any point I overlooked that could solve the freezing problem?
  2. Is there a completely different approach that may be better suited for my situation than autofs?

PS: I'm on Kubuntu 16.04

Improve this question
5
  • I wonder if your problems relate to the fact that you are using CIFS and SSHFS with autofs. I've never used it except with NFS... Commented Jan 10, 2018 at 6:32
  • The main problems definitely arise from the sshfs mount in this case. I'll try to replace it with nfs later and see if that helps. Commented Jan 10, 2018 at 8:14
  • 1
    One of the advantages that autofs provides is that it reduces the duration that network filesystems are mounted - they're mounted as needed and autofs will unmount them soon after they're no longer being used. If you suspend while a network filesystem is mounted (regardless of whether it was mounted manually or via fstab or by autofs) and resume when the remote system isn't reachable, things will likely hang. autofs wont change that. You can try umount -f /mountpoint to forcibly unmount it. Commented Jan 10, 2018 at 11:05
  • @MarkPlotnick Thanks for the wrap up, most of it was known to me. I just experience less issues when using a manual mount. When I use an alias to automatically umount and mount as desired, it causes less troubles then dealing with autofs where I also need to stop the autofs service. I would like to use autofs but together with sshfs and a lot of network and VPN disconnects its a nightmare currently. Commented Jan 10, 2018 at 22:36
  • Regarding my thinking to replace it with nfs: Since my IP address changes a lot due to different networks this is not an option. Commented Jan 10, 2018 at 22:37

2 Answers 2

Reset to default
0

If automounts are still blocked / slow to remount, when a server has become available again, it can help to explicitly restart them. First use:

systemctl list-units --type=automount

to see, which automounts are active under which name, and then use:

systemctl stop UNIT

or:

systemctl restart UNIT

as applicable. UNIT is a name from the initial list. It helped me unblock a system, that was still trying to access a gone-away NFS server, despite the automount had been cleared from fstab already and the daemon reloaded.

Improve this answer
-1

you can add "soft" option, so it generates an error when a timeout has been exceeded. By default, you are using a hard mount, meaning... it will hold on to the nfs mount and retry forever.

WARNING: soft mount will abort any i/o once the timeout has been exceeded due to errors (network timeout, etc), if there's something in the cache that's not written to the nfs mount, there's a chance you might loose it.

Improve this answer
5
  • This is incorrect, the autofs service mounts shares as needed and unmount them after a period of inactivity, so it will not hold on to the mount and retry forever. Commented Jan 10, 2018 at 6:21
  • The soft option you are talking about is only available for nfs mounts. I use sshfs and cifs here. So your answer does unfortunately not address the question. Commented Jan 10, 2018 at 8:16
  • have you tried? Isn't it that soft is a cifs mount option? linux.die.net/man/8/mount.cifs Commented Jan 10, 2018 at 14:34
  • also, he mentioned disconnect, i.e: connecting to a different network, the autofs might still be connected and the resource might still be needed. Commented Jan 10, 2018 at 14:42
  • @MontyMontemayor yes option soft is available for cifs. However, the cifs shares are not causing the problems for me, it seems that most of it relates to the sshfs share. Commented Jan 10, 2018 at 22:39

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.