sshfs permission denied even for root user
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
.
Related videos on Youtube
![Flatron](https://i.stack.imgur.com/L7ydq.jpg?s=256&g=1)
Flatron
Updated on September 18, 2022Comments
-
Flatron almost 2 years
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 usinguserx
and usingchown -R userx:groupx [...]
I expect to be able to set user permissions for files in mounted folders but this is not the case.
-
Jakuje over 8 yearsWhat 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.
-
Flatron over 8 yearsuser is
data
, data owns the remote folder on the remote machine. -
Jakuje over 8 yearsmore important would be if it owns the file you want to
chown
. If not, this is expected behaviour. You can'tchown
file you don't have access. -
Flatron over 8 yearsI did chow -R data:data /remote/folder after this using chow -R userx:groupx /local/mounted/folder --> same permission problem.
-
-
Flatron over 8 yearsUsing:
sshfs -o idmap=someuser server:/home/user/somefolder/temp/ /home/localuser/someotherfolder/
gives me:fuse: unknown option 'idmap=someuser'
-
Flatron over 8 yearsokay nvm --> idmap=someuser --> idmap=user, but still no success, I think the problem is what kubanczyk said in his answer.
-
Flatron over 8 yearsThanks 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.
-
Flatron over 8 yearsOf course I can only chown folders to the user that I mounted the folders with.
-
Diamond over 8 yearsPlease note,
idmap=user
not someuser. -
Flatron over 8 yearsYes I did, unfortnately this does not help either, nor does
allow_other
or evengid [...] uid
help. -
Flatron over 8 yearsSee 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.
-
Flatron over 8 yearsNFS 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.
-
Ashark almost 3 yearsThe exact link to bindfs example: serverfault.com/a/873259/484655 Thanks for the suggestion!