8

I use sshfs to mount a remote folder from another server to the local server. Mounting the remote folder works without a problem using the following command:

sshfs -o allow_other someServerFromSSHConfig:/home/data/somefolder/ /some/local/folder

The problem is that I cannot change the owner of the files using chown (regardless of root permissions) I always get:

chown: changing ownership of ‘/somefolder/file.img’: Permission denied

The user that accesses the folder is member of the fuse group. Even if I add additional mount options in sshfs to set the owner as userx:groupx I cannot change permissions using userx and using chown -R userx:groupx [...]

I expect to be able to set user permissions for files in mounted folders but this is not the case.

Improve this question
4
  • What is the user you are logging with to the remote server? When it is remote filesystem, you need to have access to these files with that user and not the local one. Commented Nov 15, 2015 at 14:56
  • user is data, data owns the remote folder on the remote machine. Commented Nov 15, 2015 at 14:58
  • more important would be if it owns the file you want to chown. If not, this is expected behaviour. You can't chown file you don't have access. Commented Nov 15, 2015 at 15:00
  • I did chow -R data:data /remote/folder after this using chow -R userx:groupx /local/mounted/folder --> same permission problem. Commented Nov 15, 2015 at 15:09

3 Answers 3

Reset to default
6
+50

As you said in comments, you connect as data@remote_server This means you cannot chown at all. The sshfs is just a crude abstraction, you are permitted only to the actions that you could perform inside sftp data@remote_server All abstraction are leaky, this one too.

Only root@remote_server can chown on remote_server. It doesn't matter what user you are on local_server.

Note that to sftp root@remote_server you usually need to PermitRoot yes or PermitRoot without-password in remote's /etc/ssh/sshd_config This is risky.

PS. By default, sshd doesn't allow root logins at all, because of PermitRoot no option. So normally you cannot sshfs root@remote_host. If you would like to test chown behavior via root, I would recommend to set PermitRoot without-password. This means that root can login when a public key is added to /root/.ssh/authorized_keys. With this setting, root cannot login solely by providing a root password, so it's somewhat secure.

PS2. If you need a bit more security, you can set up another instance of sshd only for this file share; with ForceCommand internal-sftp and with chroot it would have greatly increased root security, but it would need to use a new TCP port and a new firewall exception.

Improve this answer
4
  • Thanks for this answer, unfortunately as long as I add let's say userX public ssh key to the data server and mount the storage with sshfs using userX I can chown as much as I like without a problem, while when I use another user to mount the external folder (with sshfs) even setting the uid and gid to the user that will use the folder later on I won't be able to use chown as the user that I mounted the folder for. This is really strange. I don't want to add every single users ssh key to my storage server just to mount the one folder per user though. Commented Nov 19, 2015 at 19:30
  • Is there any way around this? Commented Nov 19, 2015 at 19:30
  • Of course I can only chown folders to the user that I mounted the folders with. Commented Nov 19, 2015 at 19:33
  • NFS is not an option because of security. What does PermitRoot exactly do? Currently using root on remote system to mount folders to local machine, which works but is not really an option for the long term. Commented Nov 19, 2015 at 20:36
3

If you want to set particular file ownership for sshfs mounted folder, you need to do this using uid=USER_ID_N,gid=USER_GID_N and idmap=user options.

  • uid, gid - set reported ownership of files to given values; uid is the numeric user ID of your user, gid is the numeric group ID of your user.
  • idmap - use the idmap option with user value to translate UID of connecting user. # sshfs -o idmap=user sessy@mycomputer:/home/sessy /mnt/sessy -C -p 9876 his will map UID of the remote user "sessy" to the local user, who runs this process ("root" in the above example) and GID remains unchanged.

One thing to be aware of is that your UID (User ID, the unique number of your user on a system) is not necessarily the same on the two hosts. When you ls -l, the user name associated with each file is printed in the third column. However, in the filesystem, only UIDs are stored, and ls simply looks up the UID and finds the user name associated with it. In Unix, UIDs are what matter, not the user names. So if you're 1000 on the local host and 1003 on the remote host, the sshfs mounted directory would show a different user name for your files. This is not a problem, though, because the ssh server on the remote machine is what is actually reading and writing files. So even though it shows up in ls -l as a different UID, any changes will be done through the ssh server on the remote host, which will use the correct UID for the remote machine. Problems may arise if you attempt to use a program that looks at UIDs of files (e.g. ls prints the wrong user name).

The idmap=user option ensures that files owned by the remote user are owned by the local user. If you don't use idmap=user, files in the mounted directory might appear to be owned by someone else, because your computer and the remote computer have different ideas about the numeric user ID associated with each user name. idmap=user will not translate UIDs for other users.

Quoted from: https://help.ubuntu.com/community/SSHFS

Improve this answer
5
  • Using: sshfs -o idmap=someuser server:/home/user/somefolder/temp/ /home/localuser/someotherfolder/ gives me: fuse: unknown option 'idmap=someuser' Commented Nov 19, 2015 at 19:18
  • okay nvm --> idmap=someuser --> idmap=user, but still no success, I think the problem is what kubanczyk said in his answer. Commented Nov 19, 2015 at 19:24
  • 1
    Please note, idmap=user not someuser. Commented Nov 19, 2015 at 19:42
  • Yes I did, unfortnately this does not help either, nor does allow_other or even gid [...] uid help. Commented Nov 19, 2015 at 19:44
  • 1
    See my comment on the second answer. This is pretty unbelievable, it shouldn't be that hard to mount multiple folders on a remote system to multiple folders (for separate users) on the local system, using only one user on the local machine and granting all permissions for each user so they can chown their folders for themselves. Commented Nov 19, 2015 at 19:46
1

While I didn't test your concrete use case with chown, I think I had a similar one with reading files as root on the remote server while connection as a different user to that. After some searching, I find another question exactly addressing this.

sudo

One trick is that for SSHFS a user-specific instance of the necessary SFTP server is started. SSHFS allows to configure the binary of the server to start and there's most likely sudo on the remote machine. So simply configure that to start the necessary SFTP server as root and the connecting user's permissions aren't that important at all anymore. In my case I was easily able to read all files which permission have been denied on before.

 sshfs -F /[...]/.ssh/config -o sftp_server='/usr/bin/sudo /usr/lib/openssh/sftp-server' []:/mnt/[...] /mnt/[...]

The important thing is to configure the absolute path of the binary to sudo and optionally configure /etc/sudoers.d/some_user as necessary.

bindfs

Another interesting suggested idea was to use bindfs on the remote server using SSH and afterwards SSHFS on the bound directory. bindfs can simply make permissions to be ignored. In cases like reading it might help, not sure how it would be in case of applying changes like chmod.

Improve this answer
1

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.