Nick Nobody wrote:
On Fri, 2009-04-24 at 12:04 +0200, Christian Perrier wrote:
Quoting Nick Nobody (m...@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):
nikos...@kubuntubox:~$ touch {copy,move}test; chmod 777 {copy,move}test
nikos...@kubuntubox:~$ cp copytest /mnt/smb/archives/
nikos...@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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
