31

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#[email protected]:/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#[email protected]:/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 ?

Improve this question
2
  • 1
    Ever get this figured out? I'm running into the same issue on an Ubuntu 14.04 64-bit machine.
    – glibdud
    Apr 27, 2014 at 2:27
  • Seeing the popularity of this question, compared to the number of answers, I gave up the fstab approach. I decided to bite the bullet and learn how to use Automount, addressing the big picture problem. From my experience it was "the right choice". A good introduction to Automount can be found on the Ubuntu wiki.
    – Ad N
    Apr 28, 2014 at 12:37

4 Answers 4

Reset to default
27

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.

Improve this answer
6
  • 4
    Worked for me without workaround=rename where it didn't worked before. So my only change was adding the delay_connect option, that definitely helped here! Thank you for this. Just wondering why _netdev is not enough here...
    – Nicolas
    Aug 4, 2014 at 16:59
  • 1
    That works perfectly for me, too. @Nicolas, I believe the _netdev issue is explained in Tony's answer. The network may be up, but it still can't resolve the host. Obviously, using an IP address would solve that, but who wants IP addresses in their fstab?
    – Auspex
    Jul 15, 2016 at 12:00
  • For what it's worth, somehow when I copy pasted this into atom, it picked up invisible characters that broke it. I had to remove those
    – Jonathan
    Sep 9, 2016 at 1:01
  • 4
    It mounts okay but then I get: ls /backup: Input/output error
    – Jonathan
    Sep 9, 2016 at 1:04
  • Adding 'delay_connect, workaround=rename' worked for me on Arch Linux. Thanks!
    – aSystemOverload
    May 30, 2018 at 11:38
1

Also to complement all previous comments,

  1. Make sure you allow non-root users to specify the allow_other mount option in /etc/fuse.conf

  2. Make sure you use each sshfs mount at least once manually while root so the host's signature is added to the ~/.ssh/known_hosts file.

    sshfs [user]@[host]:[remote_path] [local_path] -o allow_other,IdentityFile=[path_to_id_rsa]
Improve this answer
1
  • 1
    The allow_other mount option exposes an unresolved security bug in the Linux kernel: if the default_permissions mount option is NOT used along with allow_other, the results of the first permission check performed by the file system for a directory entry will be re-used for subsequent accesses as long as the inode of the accessed entry is present in the kernel cache - even if the permissions have since changed, and even if the subsequent access is made by a different user.
    – MountainX
    Feb 11, 2018 at 8:58
0

had the same problem, i think you need auto to be noauto. it shouldnt mount on boot, it should mount when the eth is up

Improve this answer
1
  • 6
    I think the "mount only when network ready" is already asked using _netdev, and changing with noautowould make it unable to mount at boot (only explicitly when using the mount command)
    – Ad N
    Dec 6, 2013 at 9:42
0

If you are to mount it from an authoritative DNS server's /etc/fstab and the host name of your remote SFTP server is provided by this DNS server you are certainly not going to be able to connect because the host name can not be resolved yet. Either the DNS server has to be running while attempting to mount or you have to find an alternative method to obtain your remote server's IP address.

If this is the case, you can pick any of the following solutions:

  • Add the delay_connect option so it will allow the boot sequence to continue and after the boot sequence has started the DNS server it will connect.
  • Add your remote SFTP server's host name to your local /etc/hosts file with the appropriate IP address.
  • Use your remote SFTP server's IP address in the fstab instead of host name.
Improve this answer
2
  • Can you expand on the delay_connect option? Where's it added to? Edit your question to include some more information about it.
    – AJefferiss
    Nov 9, 2015 at 8:57
  • You add it in the fstab option list: sshfs#user@host:/remote /mnt/local fuse delay_connect,uid=1000,gid=100,umask=0,allow_other 0 0
    – Tony
    Nov 10, 2015 at 10:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .