You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The man page does not explain how SSHFS permissions work.
Many users wish that when they use sshfs root@otherhost:/serverdir mountdir -o allow_other -o default_permissions and create a file as the local users myuser, the file created on the remote side is also owned by myuser (provided that myuser exists on both sides with same UID).
However, this does not work. Created files are always owned by root if root logs in remotely, and shown that way on both the local and remote side.
Currently, SSHFS applies the map file only when retrieving ownership information from the server, and (in reverse) when chown is explicitly called. The reason for that is that file creation happens on the server, and there is no way for SSHFS to specify that it should be done under a different UID - in general, this won't even be possible. When you log into a system via SSH as anything but root, any file that you create will be owned by your remote id. SSHFS is subject to the same limitations.
The only way to achieve the behavior you seem to want is to require the remote user being root, and to send an explicit chown request. I don't think this is a good idea.
sshfs does not perform chown upon file creation (openat(..., O_CREAT)) so there is no mechanism to make this work.
Repro
Execute as root:
mkdir -p /tmp/serverdir /tmp/mountdir
sshfs root@localhost:/tmp/serverdir /tmp/mountdir -o allow_other -o default_permissions
chown o+w /tmp/mountdir
sudo -u nobody sh -c 'echo hi > /tmp/mountdir/testfile'
ls -l /tmp/mountdir/testfile
when the desired output would be the file to be owned by nobody instead of root.
As a side effect, even the most basic command touch does not work as a given user over sshfs:
sudo -u nobody touch /tmp/mountdir/testfile2
prints touch: setting times of '/tmp/mountdir/testfile2': Permission denied because the touch sets the time after file creation, as nobody, but that doesn't work because sshfs creates the file owned to root.
Documentation request
My understanding is that there's currently no sshfs invocation that can make this work.
That includes -o idmap=..., -o uidfile=... and so on; none of them help in this case.
If that is true, it should be documented in the man page (likely here).
Yes, your understanding is correct. Documentation patches are welcome :-).
For the special case where the remote user is root, one could imagine a workaround where SSHFS automatically issues chown requests. But I'm not sure this is a route we should go...
The man page does not explain how SSHFS permissions work.
Many users wish that when they use
sshfs root@otherhost:/serverdir mountdir -o allow_other -o default_permissions
and create a file as the local usersmyuser
, the file created on the remote side is also owned bymyuser
(provided thatmyuser
exists on both sides with same UID).However, this does not work. Created files are always owned by
root
ifroot
logs in remotely, and shown that way on both the local and remote side.According to
sshfs does not perform
chown
upon file creation (openat(..., O_CREAT)
) so there is no mechanism to make this work.Repro
Execute as
root
:mkdir -p /tmp/serverdir /tmp/mountdir sshfs root@localhost:/tmp/serverdir /tmp/mountdir -o allow_other -o default_permissions chown o+w /tmp/mountdir sudo -u nobody sh -c 'echo hi > /tmp/mountdir/testfile' ls -l /tmp/mountdir/testfile
prints
when the desired output would be the file to be owned by
nobody
instead ofroot
.As a side effect, even the most basic command
touch
does not work as a given user over sshfs:prints
touch: setting times of '/tmp/mountdir/testfile2': Permission denied
because the touch sets the time after file creation, asnobody
, but that doesn't work because sshfs creates the file owned toroot
.Documentation request
My understanding is that there's currently no sshfs invocation that can make this work.
That includes
-o idmap=...
,-o uidfile=...
and so on; none of them help in this case.If that is true, it should be documented in the man page (likely here).
(Given that this is functionality that many users want, judging from > 100 StackExchange questions I've read on this topic today, e.g. "Preserve (local) ownerships and permissions with sshfs".)
@Nikratio Please confirm; if desired, I can also draft a wording for that.
(I also think the
chown
would be a good idea to just make this work, but this issue is just about documenting the current state for the user.)The text was updated successfully, but these errors were encountered: