I’ve been using sshfs to do remote editing on my web server. I create a directory with the server name as a mount point, owned by me in my home directory. I then mount with
$ sshfs -p <portnumber> <servername>: <mountpoint>
I also have the keys set up so it does so without a password prompt. It seems to work, but I only have read-only access — when I try to write a file it tells me that I don’t have permission. Also, I notice that when the file system is mounted, I get an owner and group of “1009” for the mount point. Is this normal? Does anyone have any idea what’s going on?
[Tuesday morning update]
D’oh! I just noticed that my line command wasn’t displaying properly before. It’s fixed now.
Owner/group of 1009 implies your local system sees those files as owned by user 1009, but doesn’t know who user 1009 is (and thus, your ID doesn’t have permission to edit his files). Not surprising, if you don’t use a common user database of some kind across the two systems.
It needs to know somehow how to map remote userids to local; based on googling “man sshfs”, I’m guessing you probably want something like “-o idmap=user”, to tell it the id of the remote user should be remapped to match that of the local. Maybe that was the default before and got lost somehow…?
OK, well that fixed the user, but how about the group? It’s still 1009. The other problem I seem to have is that there is no fuse group. Do I just create one? How would it know what it meant?
To clarify:
Actual UNIX userids are numbers, not text strings; the number-to-text string mappings are a pretty-printing aid for humans. Your userid on REMOTEHOST has is 1009; your userid locally is something else (and the fact that you may have the same label attached to both userids is irrelevant). You can easily check this by running “id” or similar on each side.
When you use sshfs to mount those files, the ‘driver’ has the permissions of user 1009 remotely, but those files are being passed through as ‘belong to 1009’. Which is fine, but your local ID isn’t 1009, so he can’t edit them. Probably local root could… but the right answer is to say ‘no, no, remote files belonging to 1009 should be treated locally as belonging to [actual local userid #].” There seems to be a sshfs option to do this; perhaps it was enabled previously somehow…
OK, well it seems to allow me to write now, even though the group is still 1009, so maybe that’s the solution.
Fuse group?
Hm. Well, sshfs doesn’t have an option to remap groups AFAIKT. The quick-and-dirty solution might be to add a 1009 group on your local host and add your local ID to it… what’s the problem, there?
Is 1009 fuse? Should I just add that group to /etc/groups with that number, then add myself to it?
The massive overkill solution would be to change your local userid/group to 1009, but you’ld have to run a script to change all files belonging to the old user id over to 1009 or you’ld lose access, so I don’t really recommend that…
On most modern UNIXen, every user gets his own private group, matching his UID (numeric userid), in addition to any other groups he belongs to. So 1009 is probably just a “rand” or whatever group on the remote box (ls -l there will tell you, or “id”). sshfs seems able to remap the users, but not groups. If you like, you could add a 1009 group (“remote-rand”) and add your local userid to it just so things will display cleanly, but it’s probably not that relevent.
My user/group number is 500. There is no current group with the ID 1009 in /etc/group.
Right… and your remote user and group are both 1009. sshfs was showing those files as belonging to 1009/1009 (and thus, 500/500 couldn’t edit them). Now it shows them as 500/1009 (because we told it to remap remote user to local user), and you have permission because you’re the user. If you like, add a 1009 group with whatever name you like (probably not a duplicatate!) to /etc/groups and it’ll still be 500/1009 but it’ll have a name for the 1009 group and you’ll be a member of it.
As I said, the other thing you could do is actually change your id to 1009/1009 and then run a script to change all files belonging to 500 to 1009, but yuck…
rand, using a relatively new FUSE ( sshfs ), try mounting with sshfs -o uid=`id -u` -o gid=`id -g`
rand, using a relatively new FUSE ( sshfs ), try mounting with sshfs -o uid=`id -u` -o gid=`id -g`
Aha, that did it. What would it look like in fstab?
I don’t think FUSE volumes go in fstab, at least not normally .. fstab is the system wide mount table, and FUSE is filesystems, done in userspace.
Well, in searching for a solution, I saw a reference to putting it in fstab.
If you want it mounted at boot-time, typically you would put it in fstab. Not sure what a fusefs entry in fstab would look like; you pile all the “-o” parameters, if any, into the 4th column (which otherwise is probably something like defaults).
fstab syntax is:
[raw device storing filesytem] [mount point] [filesystem type] [options] [archiving schedule (mostly unused)] [fsck order (0=not)]
But with sshfs, the raw device is, um, a pipe to a remote server. (Hm.) Based on 2 minutes of googling, some guy on the internet says the anwer looks like:
sshfs#username@remotehost:/remotedir /mountpoint fuse uid=500,gid=500,port=[port] 0 0
Which looks plausible to me, but no promises…
I found these instructions to be really useful as well. However, I had exactly the same problem as Donna — I see the volume mounted when I go to the Finder “Go” menu and choose “Computer”, but I do not see it on my desktop. My desktop only has a few files on it — it is not there. I tried a few times to mount it on the desktop by changing the mountpoint to /Users/nick/Desktop/ and that attempted to create an alias on the desktop, but it never quite worked. (perhaps because I had tried to mount it a few times by then and I think that repetition was making MacFusion confused.)