Mount an sshfs via macfuse at boot
Solution 1
If you maintain a remote machine, it can be really useful to mount that machine's filesystem locally to move files around. MacFuse and sshfs
make this really easy, although getting it set up and mounted automatically at login can be a bit tricky.
First, make sure you can ssh to your remote machine without entering a password. Do the setup in Leopard finally supporting ssh-agent at login and verify that it works:
ssh USER@HOSTNAME:
If it logged you in without prompting for a password or passkey, you're ready to proceed.
Next, install sshfs
and MacFuse as per Installing sshfs 1.9 with MacFuse 1.7 on OS X Leopard 10.5.5.
Figure out where you want to mount your remote volume. I wouldn't recommend using /Volumes
since it appears that OS X automatically deletes directories in there when you unmount things. So instead I used /mnt/HOSTNAME
mkdir -p /mnt/HOSTNAME
(Obviously, you'll replace HOSTNAME
with your remote server's name.)
Then make sure you can mount your remote site as a volume without specifying a password using sshfs
:
sshfs USER@HOSTNAME:PATH /mnt/HOSTNAME -oreconnect,allow_other,volname=VOLUME_NAME
Set VOLUME_NAME to whatever you want your volume to be named in the Finder. I used HOSTNAME. PATH is optional; set it to whichever directory you want to mount on the remote host. If it's not set, it'll use your home directory.
If you get no error messages,
and when you do an ls /mnt/HOSTNAME
the remote files show up, then you're ready to proceed to the next step.
Unmount the volume you just mounted:
umount /mnt/HOSTNAME
Now comes the tricky party. You'll need to create a LaunchAgent item to mount your volume at login. This in itself is pretty easy. However, if your system is anything like mine, this item won't have its SSH_AUTH_SOCK set properly, so it won't be able to login to the remote host without using a password. You'll have to manually set the SSH_AUTH_SOCK yourself.
First, create a wrapper around sshfs
that will set the SSH_AUTH_SOCK for you. Put this in a file wherever you want.
I suggest /opt/local/bin/sshfs-authsock
.
#!/bin/bash
export SSH_AUTH_SOCK=$(ls -t /tmp/launch-*/Listeners | head -1)
/opt/local/bin/sshfs $*
Basically, this file sets SSH_AUTH_SOCK to the most recent socket in your tmp directory. In most cases, this should be the proper one. It's unlikely to fail, and there's no security issue if it does.
Now you can finally create the launchd plist file. Put this in
~/Library/LaunchAgents/BACKWARDS_HOST_DNS.PATH.sshfs.plist
(If your host's path is, say, foo.niskala.org
and your PATH was /tmp
, then your resulting filename would be org.niskala.foo.tmp.sshfs.plist
.
This is just a convention, feel free to name the file whatever you want,
really; but it does need to end in .plist
.)
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>BACKWARDS_HOST_DNS.PATH.sshfs</string>
<key>ProgramArguments</key>
<array>
<string>/opt/local/bin/sshfs-authsock</string>
<string>USER@HOSTNAME:</string>
<string>/mnt/HOSTNAME</string>
<string>-oreconnect,allow_other,volname=VOLUME_NAME</string>
</array>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>
Now load the plist file and run it to see if it works.
launchctl load ~/Library/LaunchAgents/BACKWARDS_HOST_DNS.PATH.sshfs
launchctl start BACKWARDS_HOST_DNS.PATH.sshfs
If you see no error messages, see if the volume was mounted properly:
ls /mnt/HOSTNAME
If your remote files show up, then great! You're done!
If not, use
launchctl unload ~/Library/LaunchAgents/BACKWARDS_HOST_DNS.PATH.sshfs
to unload the file before making edits to it, then use ps auxwww | grep sshfs
and kill
to find and kill any sshfs
processes before trying again.
References:
- http://discussions.apple.com/thread.jspa?threadID=1674891&tstart=22
- http://ccraig.org/sshfs-mac.html
- http://code.google.com/p/macfuse/wiki/MACFUSE_FS_SSHFS
Solution 2
I'd like to update the great answer from dag729. On El Captain OS X with the OS X Fuse 2.8.3 the things are slightly different:
- Some paths are changed
- osxfuse must be forced to run in foreground mode with
-f
option -
SSH_AUTH_SOCK
is already defined so there is no more reason to create thesshfs-authsock
script
Also I would advice to don't use allow_other
option (for security reasons) and use auto_cache
option just because it sounds useful. Please check OS X Fuse mount options for details.
Here is ~/Library/LaunchAgents/NAME.sshfs.plist
file that I use:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>NAME.sshfs</string>
<key>ProgramArguments</key>
<array>
<string>/usr/local/bin/sshfs</string>
<string>[USER@]HOST:REMOTE_DIR</string>
<string>MOUNT_DIR</string>
<string>-oreconnect,auto_cache,volname=FINDER_VOLUME_NAME</string>
<string>-f</string>
</array>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>
Where NAME
is any name you like and the rest variables are quite self descriptive.
If for some reason you don't have SSH_AUTH_SOCK
defined (run command launchctl getenv SSH_AUTH_SOCK
to check it) then create a helper script, for example /usr/local/bin/sshfs-authsock
with the following content:
#!/bin/bash
export SSH_AUTH_SOCK=$(ls -t /tmp/com.apple.launchd.*/Listeners | head -1)
/usr/local/bin/sshfs $*
And run this script instead of sshfs
from plist file. So your ~/Library/LaunchAgents/NAME.sshfs.plist
should be:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>NAME.sshfs</string>
<key>ProgramArguments</key>
<array>
<string>/usr/local/bin/sshfs-authsock</string>
<string>[USER@]HOST:REMOTE_DIR</string>
<string>MOUNT_DIR</string>
<string>-oreconnect,auto_cache,volname=FINDER_VOLUME_NAME</string>
<string>-f</string>
</array>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>
Solution 3
I'd like to add something to dag729's very complete answer.
If you have Lion and have now OS X Fuse instead of the old MacFuse, then the procedure above won't work out of the box because the path of sshfs is different.
If that's the case for you, look where sshfs is in your installation using
which sshfs
and put that path in the /opt/local/bin/sshfs-authsock script.
In my installation, that path is /usr/local/bin/sshfs and therefore my script is:
#!/bin/bash
export SSH_AUTH_SOCK=$( ls -t /tmp/launch-*/Listeners | head -1)
/usr/local/bin/sshfs $*
I can confirm that the rest is still valid.
Related videos on Youtube
Ben
Updated on September 17, 2022Comments
-
Ben almost 2 years
I have 3 areas at the moment (more will come when I get this working):
Login
,User
andAdmin
. The Default route inGlobal.asax
go to the index action of the index controller in the login area (Login\Index\Index
) which works fine, this is how I mapped that:routes.MapRoute( "Default", // Route name "{area}/{controller}/{action}/{id}", // URL with parameters new { area = "Login", controller = "Index", action = "Index", id = UrlParameter.Optional }, // Parameter defaults new[] { typeof(AppName.Areas.Login.Controllers.IndexController).Namespace } );
each of the 3 areas is registered like this in the AreaRegistration files:
context.MapRoute( "Admin_default", "{area}/{controller}/{action}/{id}", new { area = "Admin", controller = "Index", action = "Index", id = UrlParameter.Optional }, new[] { typeof(AppName.Areas.Admin.Controllers.IndexController).Namespace } );
The Login controllers index action takes the users login details, looks up the type of user and redirects them to the appropriate area...... at least it should do. From what I can gather searching google, the correct way to redirect to a specific area is this:
return RedirectToAction("Action", "Controller", new { area = UserType });
which doesn't seem to work, it just redirects to
Login\Controller\Action
and I can't work out why.In my attempts to work out what was happening I used this:
var url = Url.Action("Action", "Controller", new { area = "Admin" });
which produced the same
Login\Controller\Action
url.Any help fixing this would be greatly appreciated
-
Ben over 11 yearsoh and authentication is required, but when that fails it redirects to the login with the requested url in the query string so it knows where to go once they log back in, and thats not happening so i know its not an authentication problem
-
Fabio Milheiro over 11 yearsNot following. If you have a returnUrl in the query string, why not check the login action. After logging in successfully, it needs to make use of the returnUrl argument. If not using, change it to start using
-
Ben over 11 yearsmy point is, that when authentication fails you end up with a url in the query string, but when i redirect to another area and i end up on the login screen there is no arguments in the querystring, suggesting that it was not an authentication failure sending me back to the login screen
-
Matt about 4 yearsGreat guide -- thanks. One change is I had to add
.plist
to the end of the filepath to thelaunchctl load
command, but thelaunchctl start
command does not require the .plist extension. Also, I had forgotten tochmod +x
mysshfs-authsock
file (opening Console.app revealed this mistake.) -
Matt about 4 yearsSigh, in today's MacOS 10.15.5 update, SSH_AUTH_SOCK path changed to
/private/tmp/com.apple.launchd.*/Listeners
. (Just once I want Apple to patch my OS without breaking things!)