In this article, we will delve into the issue of sshfs not automatically mounting at boot on Ubuntu, despite being properly configured in the /etc/fstab file. This issue can be quite frustrating, as it means that the filesystem has to be manually mounted by the user or through a file browser each time the system boots. We will explore some potential solutions to this problem, ensuring that you understand each step of the process.
To fix sshfs not mounting automatically at boot on Ubuntu, you can try adding the "delay_connect" option to the fstab entry, allowing non-root users to use the "allow_other" option, dealing with DNS issues by adding the remote SFTP server’s host name and IP address to the /etc/hosts file, or using the remote SFTP server’s IP address in the fstab entry. If none of these solutions work, you may want to consider using Automount instead of the fstab approach.
Understanding the Problem
The Secure Shell Filesystem (sshfs) allows you to mount a remote filesystem and interact with it as if it were local. This is done over SSH, a secure protocol that encrypts data in transit. The problem arises when the sshfs filesystem, despite being correctly set up in the /etc/fstab file with the “auto” and “_netdev” options, does not automatically mount at boot.
The “auto” option is supposed to ensure that the filesystem mounts at boot, while the “_netdev” option tells the system to wait until the network interface is up before attempting to mount the filesystem. However, in some cases, these options do not work as expected.
Solution 1: Adding the delay_connect Option
One potential solution to this problem is to add the “delay_connect” option to the fstab entry. This option tells the system to continue with the boot sequence and attempt to connect to the remote filesystem after the DNS server has started.
Here is how you can add the “delay_connect” option to the fstab entry:
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
In this command, “sshfs#user@host:/remote/dir” specifies the remote directory to be mounted, “/local/dir” is the local directory where the remote directory will be mounted, and “fuse” is the filesystem type. The “delay_connect” option is added to the list of options, along with “idmap=user” (which maps the remote user ID to the local user ID), “uid=1000,gid=1000” (which sets the user and group IDs), “umask=0” (which sets the file permissions), “allow_other” (which allows other users to access the mount), “_netdev” (which waits for the network to be up before mounting), and “workaround=rename” (which works around a renaming issue in sshfs).
Solution 2: Allowing non-root users to use allow_other
Another solution is to ensure that non-root users are allowed to specify the “allow_other” mount option. This can be done by uncommenting the “user_allow_other” line in the /etc/fuse.conf file.
Additionally, it is recommended to manually mount each sshfs filesystem as root at least once, so that the host’s signature is added to the ~/.ssh/known_hosts file. This prevents the system from asking for confirmation of the host’s identity at boot, which can cause the automatic mount to fail.
Solution 3: Dealing with DNS Issues
If the problem is related to the DNS server not being available at boot, there are a few potential solutions. One option is to add the remote SFTP server’s host name and IP address to the local /etc/hosts file. This allows the system to resolve the host name even if the DNS server is not available.
Alternatively, you can use the remote SFTP server’s IP address in the fstab entry instead of the host name. This bypasses the need for DNS resolution entirely.
Considering Alternatives: Automount
If none of these solutions work, you might want to consider using Automount instead of the fstab approach. Automount is a program that allows filesystems to be mounted when they are accessed, rather than at boot. This allows for more flexibility and can help to avoid the issues associated with mounting at boot.
The issue of sshfs not automatically mounting at boot on Ubuntu can be a complex one, with a variety of potential causes and solutions. However, by understanding the problem and carefully applying the solutions outlined in this article, you should be able to resolve the issue and ensure that your sshfs filesystems mount automatically at boot.
There can be several reasons for this issue, such as incorrect configuration in the /etc/fstab file, network connectivity problems, or DNS resolution issues.
To add the "delay_connect" option, you need to modify the fstab entry for your sshfs filesystem. Add the "delay_connect" option to the list of options, along with any other necessary options such as "idmap=user", "uid=1000,gid=1000", "umask=0", "allow_other", "_netdev", and "workaround=rename". Save the changes and reboot the system for the new configuration to take effect.
To allow non-root users to use the "allow_other" mount option, you need to uncomment the "user_allow_other" line in the /etc/fuse.conf file. Open the file with a text editor, remove the "#" symbol at the beginning of the line, save the changes, and reboot the system.
If the DNS server is not available at boot, you can either add the remote SFTP server’s host name and IP address to the local /etc/hosts file or use the remote SFTP server’s IP address in the fstab entry instead of the host name. Both methods bypass the need for DNS resolution and allow the system to connect to the remote filesystem.
Automount is a program that allows filesystems to be mounted when they are accessed, rather than at boot. It provides more flexibility and can help avoid issues related to mounting at boot. To use Automount, you need to configure it to automatically mount the sshfs filesystem when it is accessed. This can be done by creating an entry in the Automount configuration file, specifying the sshfs mount options and the mount point.