Ubuntu – sshfs is not mounting automatically at boot, despite /etc/fstab configuration

fstabmountsshfs

Setting up some Ubuntu (13.04) workstation, I am trying to have a remote filesystem mounted (over ssh).

The current config

  • I created user someuser and added it to the fuse group

  • My fstab entry reads like : 

    sshfs#someuser@remote.com:/remote_dir  /media/remote_dir/   fuse    auto,_netdev,port=22,user,allow_other,noatime,follow_symlinks,IdentityFile=/home/someuser/.ssh/id_rsa,reconnect     0       0

from my understanding :

  • auto : is explicitly asking for the remote fs to be mounted at boot
  • _netdev : wait for interface to be up before attempting to mount
  • user : allow any user to ask for this specific remote location to be mounted (useless in the perspective of the root user automatically mounting it at boot)
  • allow_other : will allow any user (in the fuse group ?) to access the mounted fs
  • IdentityFile : points to the private key paired with the public key added in the /home/someuser/.ssh/authorized_key of the remote machine.
  • reconnect : Not sure… Will attempt to reconnect if the connection is lost ?

The problem

  • At boot, I log with someuser, fire up a terminal, and /media/remote_dir is empty.

  • But from the same user (or the root), I can mount it just typing :

    mount sshfs#someuser@remote.com:/remote_dir

    It is also auto-magically mounted if I click on remote_dir in a file browser.

Any clue regarding what could be missing ?

Best Answer

I experienced the exact same problem after upgrading from Oneiric (where the automount worked fine) to Precise.

What solved the problem for me was adding the delay_connect option. In addition, I've been using the option "workaround=rename" already before, since Oneiric times. Not sure whether it is still needed today, but at least it doesn't seem to hurt.

My full /etc/fstab line is:

sshfs#user@host:/remote/dir /local/dir fuse delay_connect,idmap=user,uid=1000,gid=1000,umask=0,allow_other,_netdev,workaround=rename 0 0

You obviously would need to adapt user/group IDs to your own environment.

Related Question