Re: sshfs and permissions
2012/3/9 Tom H <tomh0665@gmail.com>:
> On Thu, Mar 8, 2012 at 1:28 PM, Camaleón <noelamac@gmail.com> wrote:
>> On Wed, 07 Mar 2012 18:27:29 +0100, Pierre Penninckx wrote:
>>
>> (...)
>>
>>> So like I said I didn't manage to make permission 100% work through
>>> sshfs, though it works on the server or through DokanFS. The ACL on the
>>> /srv/movies folder is: # file: movies
>>> # owner: root
>>> # group: videos
>>> # flags: -s-
>>> user::rwx
>>> group::rwx
>>> other::r-x
>>> default:user::rwx
>>> default:group::rwx
>>> default:other::r-x
>>> (and the default user umask is 0022)
>>>
>>> When creating a file in this directory while connect through the server
>>> (or with DokanFS), the file has these permissions:
>>> rw-rw-r-- fine.
>>> But when creating it through sshfs it have:
>>> rw-r--r-- bad.
>>> And rwxr-xr-x for folders.
>>>
>>> First, thanks for reading my long post. Second, do you have any
>>> suggestions ? I don't really know what to test.
>>
>> I Googled a bit and found some information about this problematic. For
>> instance, this blog article explains the issue quite well:
>>
>> SSHFS: fix for wrong file permissions on server
>> http://andre.frimberger.de/index.php/linux/sshfs-fix-for-wrong-file-permissions-on-server/
>>
>> I don't know if that matches for your current situation nor if it helps
>> you in any way but maybe can trigger a light in your head :-)
>
> The first paragraph of that URL mentions sftp, "SSHFS normally
> propagates the umask of the client to the server. This works great
> when the sftp server doesn’t care about the umask while creating files
> or directories. But the problem is, that the openssh sftp server
> indeed cares about the server side umask", so I checked the sshfs man
> page and it says "On the remote computer the SFTP subsystem of SSH is
> used". You should therefore be able to set the umask for sftp via the
> usual wrapper script and get the umask that you want.
>
>
> --
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: http://lists.debian.org/CAOdoSziNA6w+ru6jtgmDbu9Y03mVTPqqEj+-xDbUtcedh+R0g@mail.gmail.com
>
First, thank you for your help and sorry for the response delay.
Here are the options I used:
`-o uid=501 -o gid=20 -o umask=002`
For what I understand, the main purpose of these options are to fool
the client permissions.
In fact, it seems there's no relation between the permissions on the
server and the permissions seen from the client.
>From the client, all the folders and files are owned by 501/20
(user/group) and have a 775 permission (files also have 775 and not
664).
But the permissions are still working: the server does not allow me to
do actions I don't have permission to do.
For example, if on the server I create a file with
touch a && chmod 000 a
on the server if I `ls -l` it gives me:
---------- a
but on the client
-rwxrwxr-x a
@Camaleón:
I will make remarks on the link you provided me.
Approach 1: This doesn't work, for the reasons I said above.
Approach 2 & 3: These approaches are technically the same: fixing
the problem afterwards. This works great but I don't find it very neat
so I will use it if really necessary. Also, `inotifywatch` should do
the trick.
@Rob Owens:
I tried the `-o allow_other` but this only let me access the mounted
directory with another user on the client side. This doesn't fix the
problem.
@ Tom H:
This seems to be the problem but I must say that I don't really
understand what this paragraph means, especially this:
"But the problem is, that the openssh sftp server indeed cares about
the server side umask [...] On the remote computer the SFTP subsystem
of SSH is used. You should therefore be able to set the umask for sftp
via the usual wrapper script and get the umask that you want."
What wrapper script ?
I must apologize if I didn't make it clear before, but the problem is
not only a umask problem, it's also an ACL problem (I think).
In fact, the umask of the user on the server is 002 and when I create
a file through sshfs, the permissions are correct (755 or 644).
The thing is I added default ACLs like the `default:group` option and
it doesn't seem to be applied, though if I `getfacl` on the files
created on the client side it seems the permissions are correct.
Reply to: