SSHFS AUTOmount on Feisty

[Darwin Award Winner]

HOWTO: Automount sshfs filesystems as soon as the network becomes available.
Ubuntu Version: Feisty or later


If you are looking for a way to easily do remote backups or any other sort of mass network transfer, you have come to the wrong place. Sshfs is nice, but it tends to be unreliable under heavy load. You would be much better off looking into rsync or Unison, for example.

Update: New Features!

• Asynchronous mounting
  All sshfs mounts will be mounted at the same time, rather than waiting for each one to finish mounting before starting the next.
• Works better when run as user
  Only attempts to mount your own shares.
• Specify username rather than uid number
  e.g. uid=yourname. The script now handles both correctly.

This isn't just a howto on writing fstab lines for sshfs shares. That's part of it, yes, but the idea here is that you want you be able to walk into a cafe somewhere, start up your laptop, connect to the nearest wireless network, and immediately have your sshfs shares available without having to do anything extra beyond connecting to the network.

This howto looks long, but it really isn't; I'm just providing lots of background information for those that are interested, and for those that are not very familiar with fstab entries. A lot of this howto is a crash course in the salient points of fstab entries. If you already know these, you can skip down to the good stuff in step 3.

REQUIREMENTS:
Feisty Fawn! (or later) The versions of fuse in Edgy and earlier releases are incapable of handling sshfs lines in /etc/fstab If you don't want to upgrade to Feisty, another possible solution might be to install the fuse packages provided here. Your mileage may vary.

Next requirement: Sshfs. Sshfs is the tool used to mount any remote folder that you can access via ssh as a filesystem. To install it,

sudo apt-get install sshfs

That should also install any other dependencies, including Fuse, if they aren't already installed.

Finally, and very importantly, you must have set up PASSWORDLESS login to the ssh host that you wish to mount. For details on how to set this up, go here. A non-automatic variation of this howto is possible without passowrdless logins.

Also, you should already know how to mount your sshfs shares manually. There are plenty of howto's for this on these forums and elsewhere.

PROCEDURE:
Before you can automount your shares, you first have to mount them, and you have top set them up in your /etc/fstab so that they can be mounted with a simple command. So,

STEP 1: Setting up fstab and fuse.conf.
My source for this section is this page (the same one mentioned above). /etc/fstab is a critical system file, so naturally you will need administrator privileges to edit it:

gksu gedit /etc/fstab

A typical sshfs fstab entry ready for automounting looks something like this:

# <file system>       <mount point>         <type>  <options>
sshfs#myname@www.myhome.com:/home/myname    /mnt/sshfs/homebox    fuse    comment=sshfs,noauto,users,exec,uid=1000,gid=1000,allow_other,reconnect,transform_symlinks,BatchMode=yes 0 0

If you're familiar with fstab entries, the only thing that should look new is the filesystem specification at the beginning of the line. If you're new at this, I'll provide a quick explanation. The first part determines the sshfs share. The syntax is the same as when you are using sshfs on the command line, except that it is prefixed by "sshfs#" to tell the mount program what kind of filesystem this is. (By the way,This kind of syntax probably works for other fuse filesystems as well, but I haven't tried it.) Also, make sure to put your username in, or else the system will not know which user to log in to the remote host as.

The next part is the mount point. Again, you can simply use the same folder that you always use when you mount the share manually. The next part tells mount that this is a Fuse filesystem.

The options are also the same options you use when you mount the share manually, with a few additions:

• comment=sshfs
  This option is just what it says: a comment. We'll see later how the automount script uses this.
• users
  This option allows anyone to mount this filesystem. Without this, you could only mount the filesystem using sudo. Allowing normal users to mount the share isn't strictly necessary for automatic operation, but it allows you to easily remount the share manually if something goes wrong during the automatic mount. (If you know how to edit the sudoers file, feel free to do that instead of using the "users" option; if you don't know what the sudoers file is, don't worry about it - The "users" option is good enough.)
• uid and gid
  These two options are required because when the sshfs share is automounted, it won't be you running the mount program; it will be the system, and the system needs to know who the share belongs to. To find out your uid and gid, simply open a terminal and run "id". Use the numbers that it tells you, not the numbers given in the example above.
  noauto
  This tells the system not to mount the filesystem when it first boots. (because the network isn't up yet!)
• BatchMode=yes
  This tells the sshfs process not to try asking for a password, because the automount script certainly isn't going to provide one. With this option, if you don't have passwordless logins working correctly, you'll know immediately; you won't have to waste time cancelling a password prompt.
  Secondly, this option tells ssh not to allow idle timeouts. Without this, your sshfs mounts will unmount if you don't touch them for a while.

Next, you should put the following in /etc/fuse.conf (create the file if it doesn't exist):

user_allow_other

STEP 2: Testing Your Fstab entries
(If you already know how to do this, then go ahead and do it, then skip to step 3.)
To see if your fstab entry works, open up a terminal and try to mount it like this (I will continue with the example above):

mount /mnt/sshfs/homebox

Then see if your sshfs share has been successfully mounted, for example, by:

ls /mnt/sshfs/homebox

If you see the contents of your remote share, then you're good to go.

At this point, if you have not set up passwordless ssh logins, then mounting will still work, but you will have to provide your password on each mounting, and step 3 will not work for you.

STEP 3: Automounting your shares when you connect to the internet
Ok, now that your computer knows how to mount your shares, it's time to tell it when to mount them. Also, just as importantly, you need to tell your compute when to unmount them as well, because if you lose your network connection and forget to unmount the shares, any program that tries to access them will freeze indefinitely and will need to be killed.

Accomplishing both of these is actually quite easy. You should have a pair of directories called /etc/network/if-up.d and /etc/network/if-down.d. Scripts in the first directory will be executed when the computer connects to the network, and scripts in the second one will be executes when it disconnects. Again, editing files in these directories requires administrator privileges. Create the following two files:
/etc/network/if-up.d/mountsshfs

#!/bin/sh

## http://ubuntuforums.org/showthread.php?t=430312
## The script will attempt to mount any fstab entry with an option
## "...,comment=$SELECTED_STRING,..."
## Use this to select specific sshfs mounts rather than all of them.
SELECTED_STRING="sshfs"

# Not for loopback
[ "$IFACE" != "lo" ] || exit 0

## define a number of useful functions

## returns true if input contains nothing but the digits 0-9, false otherwise
## so realy, more like isa_positive_integer 
isa_number () {
    ! echo $1 | egrep -q '[^0-9]'
    return $?
}

## returns true if the given uid or username is that of the current user
am_i () {
	[ "$1" = "`id -u`" ] || [ "$1" = "`id -un`" ]
}

## takes a username or uid and finds it in /etc/passwd
## echoes the name and returns true on success
## echoes nothing and returns false on failure 
user_from_uid () {
    if isa_number "$1"
    then
		# look for the corresponding name in /etc/passwd
    	local IFS=":"
    	while read name x uid the_rest
    	do
        	if [ "$1" = "$uid" ]
			then 
				echo "$name"
				return 0
			fi
    	done </etc/passwd
    else
    	# look for the username in /etc/passwd
    	if grep -q "^${1}:" /etc/passwd
    	then
    		echo "$1"
    		return 0
    	fi
    fi
    # if nothing was found, return false
   	return 1
}

## Parses a string of comma-separated fstab options and finds out the 
## username/uid assigned within them. 
## echoes the found username/uid and returns true if found
## echoes "root" and returns false if none found
uid_from_fs_opts () {
	local uid=`echo $1 | egrep -o 'uid=[^,]+'`
	if [ -z "$uid" ]; then
		# no uid was specified, so default is root
		echo "root"
		return 1
	else
		# delete the "uid=" at the beginning
		uid_length=`expr length $uid - 3`
		uid=`expr substr $uid 5 $uid_length`
		echo $uid
		return 0
	fi
}

# unmount all shares first
sh "/etc/network/if-down.d/umountsshfs"

while read fs mp type opts dump pass extra
do
    # check validity of line
    if [ -z "$pass" -o -n "$extra" -o "`expr substr ${fs}x 1 1`" = "#" ]; 
    then
        # line is invalid or a comment, so skip it
        continue
    
    # check if the line is a selected line
    elif echo $opts | grep -q "comment=$SELECTED_STRING"; then
    	
    	# get the uid of the mount
        mp_uid=`uid_from_fs_opts $opts`
        
        if am_i "$mp_uid"; then
			# current user owns the mount, so mount it normally
			{ sh -c "mount $mp" && 
				echo "$mp mounted as current user (`id -un`)" || 
				echo "$mp failed to mount as current user (`id -un`)"; 
			} &
		elif am_i root; then
			# running as root, so sudo mount as user
			if isa_number "$mp_uid"; then
				# sudo wants a "#" sign icon front of a numeric uid
				mp_uid="#$mp_uid"
			fi 
			{ sudo -u "$mp_uid" sh -c "mount $mp" && 
				echo "$mp mounted as $mp_uid" || 
				echo "$mp failed to mount as $mp_uid"; 
			} &
		else
			# otherwise, don't try to mount another user's mount point
			echo "Not attempting to mount $mp as other user $mp_uid"
		fi
    fi
    # if not an sshfs line, do nothing
done </etc/fstab

wait

/etc/network/if-down.d/umountsshfs

#!/bin/bash

# Not for loopback!
[ "$IFACE" != "lo" ] || exit 0

# comment this for testing
exec 1>/dev/null # squelch output for non-interactive

# umount all sshfs mounts
mounted=`grep 'fuse.sshfs\|sshfs#' /etc/mtab | awk '{ print $2 }'`
[ -n "$mounted" ] && { for mount in $mounted; do umount -l $mount; done; }

Now make both files executable and owned by root:

sudo chmod 755 /etc/network/if-up.d/mountsshfs /etc/network/if-down.d/umountsshfs
sudo chown root:root /etc/network/if-up.d/mountsshfs /etc/network/if-down.d/umountsshfs

That should be it! If your shares are configured as above, they should now automatically mount and unmount with your network. Try disconnecting and reconnecting.

ADDITIONAL COMMENTS:
As an added bonus, since these shares are in fstab, GNOME will automatically create desktop icons for them when they are mounted, so you will have easy access to them.

Those more familiar with mount might point out that the -a option could be used in these scripts instead of loops and grep, awk, etc. Indeed, my first implementation used this. However, the current form of the scripts allows them to be executed successfully by any user.

By the way, remember that comment option? Well, that's how the mounting script knows which filesystems to mount.

The mounting script can also be run manually at any time to remount your shares. There is no need to use sudo. When run as a user, the script will only remount your shares.

When, your computer boots, it may complain that the fstab lines that you entered are invalid, but nothing should go wrong.

And lastly, like most of the open source/free software world, this guide comes with no warranty.

UPDATE

In Hardy Heron and above, there is a bug in sshfs that prevents non-root unmounting of sshfs. There is a workaround described in https://bugs.launchpad.net/ubuntu/+s...se/+bug/243298 that makes things work for now. You can try the following perl one-liner to automatically apply the workaround to your fstab, but I only guarantee that it worked for me:

sudo perl -lape 's/(sshfs#\S+)(\s+\S+\s+\S+\s+)(.*)/\1\2fsname=\1,\3/' -i /etc/fstab

Thanks to conchyliferous for bringing this to my attention.

[wildlifer]

Thanks. I use Xubuntu and I now have an easy way to access ssh shares (thunar does not have native ssh browsing support).

[Barleyman]

How do you do this on an alternate port?

[Darwin Award Winner]

Originally Posted by Barleyman How do you do this on an alternate port?

$ sshfs -h 2>&1 | grep -i port
    -p PORT                equivalent to '-o port=PORT'
    -o directport=PORT     directly connect to PORT bypassing ssh

So you'll have to add "port=22" or whatever port you want to the filesystem options in /etc/fstab. There's also an way to pass options to ssh. You could specify the port or any number of other things that way.

[ernstblaauw]

My entry in fstab looks like this:

sshfs#xxxxxx@rattler.few.vu.nl:/home/xxxxxx/	/media/VU	fuse	comment=sshfs,users,noauto,uid=1000,gid=1000,allow_other,reconnect,transform_symlinks	0	0

As I have a password login, I'm not going to auto mount. However, when I type sudo mount /media/VU, I get the following error:

/sbin/mount.fuse: 23: function: not found
-e mount.fuse# sshfs#xxxxxx@rattler.few.vu.nl:/home/xxxxxx/
exit: 26: Illegal number: /media/VU

What's going wrong?

Update
I installed FUSE 2.6.5, and now I get this output:

[: 54: ==: unexpected operator
[: 54: ==: unexpected operator
[: 54: ==: unexpected operator
[: 54: ==: unexpected operator
[: 54: ==: unexpected operator
[: 54: ==: unexpected operator
[: 54: ==: unexpected operator
[: 54: ==: unexpected operator
[: 54: ==: unexpected operator
[: 54: ==: unexpected operator
[: 54: ==: unexpected operator
[: 54: ==: unexpected operator
Password:
fuse: unknown option `IGNORE'

(By 'Password:' I entered my password)

The share is not mounted

[Darwin Award Winner]

Fuse 2.6.5? The latest version of Fuse in Feisty (i.e. the one that I am using) is 2.6.3. I don't know if something might have changed between those two versions. Anyway, you can try the following:

• Try mounting without sudo. The 'users' option should make this unnecessary, and this could be a possible problem, though I doubt it.
• Make sure you can log in via ssh. Again, probably not the problem, but you should make sure.
• Make sure you can mount your remote directory using sshfs directly.
• Make sure the mount directory already exists. I think Ubuntu might have some way of cleaning out the /media directory. That's why I showed my example in /mnt.

Please try those and let me know what happens. If you solve your problem, I'd like to be able to update my guide.

[Barleyman]

Originally Posted by Darwin Award Winner $ sshfs -h 2>&1 | grep -i port -p PORT equivalent to '-o port=PORT' -o directport=PORT directly connect to PORT bypassing ssh So you'll have to add "port=22" or whatever port you want to the filesystem options in /etc/fstab. There's also an way to pass options to ssh. You could specify the port or any number of other things that way.

Sorry, I should have explained my problem a little better. I was aware of how to switch the port using the -p option. This currently works fine for my little shell script I launch to mount the drive. But I couldn't seem to find the correct sytax to make it work via fstab.

your pointer to filesytem options gave me a clue, so I decided to read through the documentation of fstab and found the solution that works for me.

sshfs#me@remoteserver:/remote/folder/ /media/myserver fuse port=123,noauto,user 0 0

Thanks again.

[ernstblaauw]

Originally Posted by Darwin Award Winner Fuse 2.6.5? The latest version of Fuse in Feisty (i.e. the one that I am using) is 2.6.3. I don't know if something might have changed between those two versions. Anyway, you can try the following: Try mounting without sudo. The 'users' option should make this unnecessary, and this could be a possible problem, though I doubt it. Make sure you can log in via ssh. Again, probably not the problem, but you should make sure. Make sure you can mount your remote directory using sshfs directly. Make sure the mount directory already exists. I think Ubuntu might have some way of cleaning out the /media directory. That's why I showed my example in /mnt. Please try those and let me know what happens. If you solve your problem, I'd like to be able to update my guide.

• Mounting without sudo doesn't work.
• I can log in via ssh

Then, I reinstalled FUSE and sshfs by going to synaptic and marking them for reinstallation. Then, I used another mounting point. I had to add 'user_allow_other' to fuse.conf (this was a message when I tried to mount). And guess what.. it works now .

I got another question: I really need a password to log in. Is it possible to store it somewhere and then use it to automatically log in?

[prankst3r]

For those of you asking about being able to mount sshfs without a password, you can setup a trust relationship between your local and remote machines as follows:

Make sure you are logged in as the user you want to set up the trust relationship. Then go to your home directory on your client machine:

cd $HOME

Then generate a public/private rsa key pair:

 ssh-keygen -t rsa

Leave all the fields as default (just press enter). Do not enter a passphrase unless you want to enter that everytime you establish an ssh/sshfs connection (which I assume you don't since we wanted to eliminate a password/passphrase prompt to begin with).

Now go ahead and enter your .ssh directory:

cd $HOME/.ssh

Establish an sftp connection to the server box:

sftp <login>@<server_name>:/home/<login>/.ssh

put id_rsa.pub

*Note <login> refers to the server login you want to establish the trust relationship with.

Then quit sftp and ssh to the server box from your client box:

ssh <login>@<server_name>:/home/<login>/.ssh

Now you will need to append your client's public key to the authorized keys as follows:

cat id_rsa.pub >> authorized_keys

Next make sure permissions on authorized_keys are 600:

chmod 600 authorized_keys

And thats it - you now have a trust relationship setup between the client login you setup the rsa key and the server login whose authorized key list you added the client's public key to.

Go ahead and test out an ssh or sftp connection from your client box to make sure it is working:

ssh <login>@<server_name>

I certainly don't claim to be any sort of Linux guru, so feel free to point out anything that could be done better - as far as I know you can't automate this with a passphrase when generating the rsa key, but I could be wrong. Cheers.

[lindsay_keir]

Passwordless Logons
Here's a simpler method

# Create a public key-pair for whichever user you are using on the local PC
ssh-keygen -t rsa
# Give the user's public key to admin1@myServer
ssh-copy-id -i .ssh/id_rsa.pub admin1@myServer
# ... admin1@myserver's password:XXXXXX # You must know admin1's password
# The user can now automatically connect as admin1
ssh admin1@myServer @myserver
This saves all that copying, etc.

I did the same for the local PC's root account
# Switch to the root account
su -

I got this from Item 6 at http://www.venturecake.com/10-linux-...know-for-once/

Thanks to both of you - I spent hours screwing this up and never did get it to work until now.