sshfs permission denied even for root user

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.

Solution 1:

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.

Solution 2:

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

Solution 3:

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.