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=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
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
