[Pkg-samba-maint] Bug#525321: Bug#525321: Bug#525321: samba: "force create mode" option no longer works

[Luk Claes]

Nick Nobody wrote:
> On Fri, 2009-04-24 at 12:04 +0200, Christian Perrier wrote:
>> Quoting Nick Nobody (me at nikosapi.org):
>>
>>>> What happens when you copy the file ?
>>>>
>>>> I see the same behaviour than the one you see, with 3.3.3. However,
>>>> copying the file ends up with the right permissions.
>>>>
>>>> I'm not entirely sure that what you see is a bug, actually. After all,
>>>> when moving a file, you expect permissions to remain as they are.
>>>>
>>>>
>>> The same thing occurs even if I copy a file.
>> It doesn't on my side. Copying a file ends up with the expected
>> permissions.
>>
>> Which is why I assume that experiencing the problem with "mv" only is
>> IMHO maybe not a bug.
> 
> If this is isn't a bug, then what's the point of the "force create mode"
> option? Whether I'm copying or moving a file to the samba share, I'm
> still *creating* a new file on the remote server. All newly created
> files should at least have the same permissions as "force create mode".
> 
> This seems to be pretty clearly laid-out in the smb.conf man page:
> 
>     create mask (S)
> 
>     When a file is created, the necessary permissions are calculated
>     according to the mapping from DOS modes to UNIX permissions, and
>     the resulting UNIX mode is then bit-wise ´AND´ed with this
>     parameter. This parameter may be thought of as a bit-wise MASK for
>     the UNIX modes of a file. Any bit not set here will be removed from
>     the modes set on a file when it is created.
> 
>     The default value of this parameter removes the group and other
>     write and execute bits from the UNIX modes.
> 
>     Following this Samba will bit-wise ´OR´ the UNIX mode created from
>     this parameter with the value of the force create mode parameter
>     which is set to 000 by default.
> 
>>> I'm pretty sure this is a bug, in the smb.conf manpage it says that the
>>> mode given to the "force create mode" gets OR'd with the file's
>>> permissions. This guarantees that you'll always have at *least* whatever
>>> "force create mode" is set to. The way I understand this is: "create
>>> mask" strips away permissions and "force create mode" adds them, no?
>>
>> If I could reproduce the bug when copying a file, I would
>> agree. However I am not..:-)
>>
>> Have you considered checking the "umask" settings which you're using?
>>
> 
> Both the server and the client have a default umask of 0022 and I've
> tried mounting the share with umask=0000 and that doesn't help.
> 
> Another weird thing I've noticed (which is not in 3.0.24-6etch10):
> 
> nikosapi at kubuntubox:~$ touch {copy,move}test; chmod 777 {copy,move}test
> nikosapi at kubuntubox:~$ cp copytest /mnt/smb/archives/
> nikosapi at kubuntubox:~$ mv movetest /mnt/smb/archives/
> 
> teh-server:~# ls -l /mnt/md1/archives/{copy,move}test
> -rwxr-xr-x 1 samba samba 0 2009-04-24 15:41 /mnt/md1/archives/copytest
> -rwxrwxrwx 1 samba samba 0 2009-04-24 15:40 /mnt/md1/archives/movetest

This is because a umask has no effect on a move operation, but it does 
on a copy operation.

> Shouldn't the execute bits be wiped out by my "create mask" (0664)? And
> why are the group and others' write bits being removed when copying?

I guess copying nor moving is seen as creating a file. What's the 
behaviour if you save a new file on the share?

Cheers

Luk