Bug#525321: [Pkg-samba-maint] Bug#525321: Bug#525321: samba: force create mode option no longer works
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= 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
Bug#525321: [Pkg-samba-maint] Bug#525321: Bug#525321: samba: force create mode option no longer works
On Fri, 2009-04-24 at 22:30 +0200, Luk Claes wrote:
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= 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
nikos...@kubuntubox:~$ touch /mnt/smb/archives/testfile
teh-server:~# ls -l /mnt/md1/archives/testfile
-rw-r--r-- 1 samba samba 0 2009-04-24 16:30 /mnt/md1/archives/testfile
When using the older version (3.0.24-6etch10) I get the expected result:
-rw-rw-r-- 1 samba samba 0 2009-04-24 16:29 /mnt/md1/archives/testfile
nick
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525321: [Pkg-samba-maint] Bug#525321: Bug#525321: samba: force create mode option no longer works
On Fri, Apr 24, 2009 at 10:30:15PM +0200, Luk Claes wrote:
Both the server and the client have a default umask of 0022 and I've
tried mounting the share with umask= 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.
More precisely, the cp command calls:
open(foo, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
open(bar, O_WRONLY|O_TRUNC) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
read(3, , 4096) = 0
close(4)= 0
close(3)= 0
and the mv command calls:
rename(foo, /home/vorlon/baz) = -1 EXDEV (Invalid cross-device link)
unlink(/home/vorlon/baz) = -1 ENOENT (No such file or directory)
open(foo, O_RDONLY|O_NOFOLLOW)= 3
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
open(/home/vorlon/baz, O_WRONLY|O_CREAT|O_EXCL, 0600) = 4
fstat(4, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
read(3, , 4096) = 0
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
fchmod(4, 0100644) = 0
^^
close(4)= 0
close(3)= 0
So when you have Unix extensions enabled, the chmod operation is honored,
overriding any defaults set on open by 'force create mode'.
If you don't want Unix modes on the client to be honored, you should disable
unix extensions.
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?
Both create a file, but in one case the initial perms are overridden.
So if the only concern is the permissions when using 'mv', I would say this
is not a bug.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525321: [Pkg-samba-maint] Bug#525321: Bug#525321: samba: force create mode option no longer works
On Fri, 2009-04-24 at 16:47 -0700, Steve Langasek wrote: So when you have Unix extensions enabled, the chmod operation is honored, overriding any defaults set on open by 'force create mode'. If you don't want Unix modes on the client to be honored, you should disable unix extensions. That makes sense, I recall reading that unix extensions (or something that has to do with that setting) for the etch version of samba was broken (it also explains some errors I'd get when doing certain file operations). I disabled unix extensions with version 2:3.2.5-4lenny2 and sure enough, it works. Thanks for your help and sorry for wasting your time, nick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
