permissions on samba share change automatically

javeree · Guru Joined: 29 Jan 2006 Posts: 455

First of all some information:

in /etc/fstab

javeree_work · Tux's lil' helper Joined: 13 Apr 2005 Posts: 84

I saw that permissions are not the only thing that changes. after doing ls -ld test6, the number immediately after the permissions decreases too. According to `man ls`, this number indicates the number of links to the file. However, no links are involved at all ?

desultory · Bodhisattva Joined: 04 Nov 2005 Posts: 9410

Moved from Desktop Environments to Networking & Security.

KWhat · l33t Joined: 04 Sep 2005 Posts: 660 Location: Los Angeles

javeree_work · Tux's lil' helper Joined: 13 Apr 2005 Posts: 84

I found out what is the probable cause of the problem above, but not what the solution is.

I tried the above mentioned commands, but using different umasks on the client. I saw that when a directory is created, the (incorrect) permissions it gets are the ones specified by the umask, not the ones specified by the dir_mask from the mount command. The problem lies in the fact that the same thing does not happen with the user/group id. There, the options specified in the mount copmmand are appied immediately. This leads to a status where permission for the creating user are applied to the userid of the mount command instead.

In detail I think this happens:

1. The client creates a directory: the samba protocol sends that to the server, who actually creates the directory using local rules (probably with owner guest/everybody).

2. The cifs client remembers (caches) it created the directory with the umask of local user, but forgets (not-cached) that uid, and applies the mount specified uid instead. Therefore a umask specifying 'only the local user may write' now effectively says 'only the userid specified on the mount command may write'. This effectively prevents the creating user from accessing its own directory. I believe this is a bug, and should be corrected.
An ls -l command shows 2 hard links, which would correspond to the cached info and the uncached info being not equal.

3. Only some commands require the client to query the server again. Only as of that moment, does the client read from the server that the directory exists, and that it should be presented with the permissions as specified in the dir_mask. It throws away the incorrect cached info (thereby reducing the number of links), and applies the permissions that match the uid in the mount command, which now say 'users in the group (which happens to include the creating user) have write access'

In my opinion, one of two possible behaviours should be implemented:

A. the client caches not only the umask permissions, but also the creating user. As long as the server data has not been re-read, it looks as though the creating user has access rights according to the umask. the mount uid/gid is only applied when the mount dir_mask is applied.

B. permissions are not cached and dir_mask is applied immediately.

Maybe such a behaviour is already implemented, and it may be possible to specify what the cifs client does by activating some option in the mount command. However, I was unable to find any such option.

Alternatively, I will file a bug report to the cifs client upstream