I have a question about file permissions and how they are affected by a
client's umask.
To illustrate my question, I issued the following commands first on a
local ext3 file system and
then on a cifs file system:
$ umask 0002
$ touch f1
$ echo xx > f2
$ umask 0022
$ touch f3
$ echo xx > f4
$ ls -l
On Ext3, the output is:
-rw-rw-r-- 1 abdv29 users 0 Oct 9 00:31 f1
-rw-rw-r-- 1 abdv29 users 3 Oct 9 00:31 f2
-rw-r--r-- 1 abdv29 users 0 Oct 9 00:31 f3
-rw-r--r-- 1 abdv29 users 3 Oct 9 00:31 f4
On a CIFS mount the output is:
-rw-rw-r-- 1 abdv29 users 0 Oct 9 00:35 f1
-rw-rw-r-- 1 abdv29 users 3 Oct 9 00:35 f2
-rw-r--r-- 1 abdv29 users 0 Oct 9 00:35 f3
-rw-rw-r-- 1 abdv29 users 3 Oct 9 00:35 f4
The relevant section from smb.conf on the samba server is:
[common]
comment = Common Area
path = /common
read only = no
valid users = @users
create mask = 0660
force create mode = 0660
force directory mode = 775
write list = @users
force group = users
directory mask = 0775
The share is mounted on a Linux system with the following command:
mount.cifs //localhost/common /mnt/smb -o
rw,uid=600,gid=504,user=abdv29,password=*******
>From what I have understood of the samba documentation, the various file
creation masks specified
by Samba do not override a client umask.
If that is so, I would expect that the permissions for file "f4" on the
cifs mount should be 644
(rw-r--r--) rather than 664 which it is.
Can someone please explain why on the CIFS mount, with a umask of 0022,
files created with "touch"
and "echo" end up with different group permissions? (Noting of course
that on a non CIFS file system,
these commands produce files with identical permissions).
The above seems inconsistent to me. My aim is to have a Samba share on
which all files created
will be group writable - I expect to have Windows users, Mac users and
Linux users. I would rather not
have to ask all the Mac and Linux users to change their umasks to
0002 ... or is this the only
solution?
I am using Samba version 3.2.3-0.20 on Fedora 9.
Thanks in advance.
Gerry.
------------------------------------------------------------
This message has been scanned for viruses and dangerous content
by MailScanner and is believed to be clean.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba
You understood wrong. The server setting override all client
requests. That's why they're *force* create mode.
Jeremy.
Thanks - that does make sense.
Can you tell me then why "/bin/touch" appears immune to the Samba
settings?
Gerry.
On Wed, 2008-10-08 at 11:48 -0700, Jeremy Allison wrote:
> On Thu, Oct 09, 2008 at 12:58:41AM +1100, Gerry Marthe wrote:
> >
> > The relevant section from smb.conf on the samba server is:
> >
> > [common]
> > comment = Common Area
> > path = /common
> > read only = no
> > valid users = @users
> > create mask = 0660
> > force create mode = 0660
> > force directory mode = 775
> > write list = @users
> > force group = users
> > directory mask = 0775
> >
> > The share is mounted on a Linux system with the following command:
> >
> > mount.cifs //localhost/common /mnt/smb -o
> > rw,uid=600,gid=504,user=abdv29,password=*******
> >
> > >From what I have understood of the samba documentation, the various file
> > creation masks specified
> > by Samba do not override a client umask.
>
> You understood wrong. The server setting override all client
> requests. That's why they're *force* create mode.
>
> Jeremy.
>
>
> ------------------------------------------------------------
>
> This message has been scanned for viruses and dangerous content
> by MailScanner and is believed to be clean.
>
------------------------------------------------------------
This message has been scanned for viruses and dangerous content
by MailScanner and is believed to be clean.
--
If you can make the CIFS client violate the
"forced" settings on the Samba server that's
a server bug and I'll fix it.
Can you give me a specific example of this
happening (with Samba and CIFSFS version numbers
please) ?
Jeremy.
Specific example:
/* As root, issue the following mount command from client. */
mount.cifs //10.0.1.5/common /mnt/smb -o
rw,uid=500,user=abdv29,password=*******
/* Switch user to "abdv29" */
su - abdv29
/* Change directory to where the CIFS filesystem is mounted. */
cd /mnt/smb
/* Set umask */
umask 0022
/* Create a couple of files using "touch" and "echo". */
touch f1
echo "xx" >f2
/* On a local EXT3 filesystem, I would expect the two files
created above to each have the following symbolic permission:
"rw-r--r--" and this is indeed so.
On the CIFS mount, I would expect the "force create mode" to
override the umask in both cases, giving symbolic permission of:
"rw-rw-r--"
This is so only for the file named "f2" created with
"/bin/echo". The file created with "/bin/touch" has symbolic
permissions of: "rw-r--r--" indicating that the client has
violated the Server "force" settings.
*/
I have verified this happens with the following Samba versions:
1) Samba server version 3.0.28 running on RHEL-5
Samba client version 3.2.3 running on Fedora 9.
"mount.cifs -V" does not show version number, just display usage
message.
2) Samba server version 3.2.3 running on Fedora 9.
Samba client version 3.0.28 running on RHEL-5.
"mount.cifs -V" show version 1.0
Let me know if you need more information.
Gerry.
On Wed, 2008-10-08 at 17:24 -0700, Jeremy Allison wrote:
> On Thu, Oct 09, 2008 at 11:18:49AM +1100, Gerry Marthe wrote:
> > Hi Jeremy,
> >
> > Thanks - that does make sense.
> > Can you tell me then why "/bin/touch" appears immune to the Samba
> > settings?
>
> If you can make the CIFS client violate the
> "forced" settings on the Samba server that's
> a server bug and I'll fix it.
>
> Can you give me a specific example of this
> happening (with Samba and CIFSFS version numbers
> please) ?
>
> Jeremy.
>
>
> ------------------------------------------------------------
>
> This message has been scanned for viruses and dangerous content
> by MailScanner and is believed to be clean.
>
------------------------------------------------------------
This message has been scanned for viruses and dangerous content
by MailScanner and is believed to be clean.
--