Samba file access by GID - what am I missing???

[Darren Nickerson]

Folks,

Samba version 2.0.5a, as shipped with RedHat Linux 6.1.

There may be an obvious answer to the problem I am facing, but no matter how 
many times I leave it and come back to it, I'm still unable to see what I'm 
doing wrong. Please can anyone help? I'm trying to

Here's the problem. I have reason to want a directory tree to be writable by 
virtue of the GID of users accessing it only.

Here's the directory I'm trying to share, and an example of the files I would 
like to have in it:

[root at ducent /]# ls -al /test
total 8
d--xrwx--x   2 nobody   sgml         4096 Mar 18 13:52 .
drwxr-xr-x  23 root     root         4096 Mar 18 03:07 ..
----rw----   1 nobody   sgml            0 Mar 18 13:44 test3.txt

Now, I can achieve the behavior I am after in UNIX:

[root at ducent /test]# su sgml
[sgml at ducent /test]$ id
uid=503(sgml) gid=700(sgml) groups=700(sgml)
[sgml at ducent /test]$ ls -l test3.txt 
----rw----   1 nobody   sgml            0 Mar 18 13:44 test3.txt
[sgml at ducent /test]$ touch test3.txt 
[sgml at ducent /test]$ ls -l test3.txt 
----rw----   1 nobody   sgml            0 Mar 18 16:29 test3.txt
[sgml at ducent /test]$ echo "test" > test3.txt 
[sgml at ducent /test]$ ls -l test3.txt 
----rw----   1 nobody   sgml            5 Mar 18 16:29 test3.txt
[sgml at ducent /test]$ 

So I can touch the file, I can overwrite it, no problemo. And it's because of 
the group write permission on both the directory, and the file. No problem, 
this I understand.

Now let's share this out in Samba:

[testshare]
   comment = Testing access by GID
   path = /test
   valid users = darren
   public = no
   writable = yes
   printable = no
   force user = sgml

I'm using:

# This option is important for security. It allows you to restrict
# Security mode. Most people will want user level security. See
# security_level.txt for details.
   security = user

So samba authenticates me according to my UNIX password, which is the same as 
my Windows one, and then as I understand it the "force user" switches me to 
UID sgml, and also (this is the subtle bit) I inherit the primary GID of the 
user sgml.

[root at ducent /test]# egrep sgml /etc/passwd
sgml:x:503:700::/home/sgml:/bin/bash
[root at ducent /test]# egrep sgml /etc/group 
sgml:x:700:

When I mount the share, I see:

=====================================================
Service      uid      gid      pid     machine
----------------------------------------------
testshare    sgml     sgml      5629   dazza    (10.0.0.1) Sat Mar 18 16:38:54 
2000

No locked files
=====================================================

Right, I expected this. I'm sgml.sgml now. Great! I should have write access, 
right? Well, I don't. The test file (mode ----rw----) is marked read-only. I'm 
unable to write to it. If I get the properties of this file on Win95, I see:

=====================================================
Locked files:
Pid    DenyMode   R/W        Oplock           Name
--------------------------------------------------
5629   DENY_WRITE RDONLY     EXCLUSIVE+BATCH  /test/test3.txt   Sat Mar 18 
16:41:46 2000
=====================================================

I'm not sure I understand the oplock here, but no matter, the point remains 
that I am unable to write to (or overwrite the file). WHAT? WHY NOT???

Here's an additional rub. I can place NEW files in this directory. I can 
create as many files as I like. I'll create a new file, and a new directory:

[root at ducent /test]# ls -al
total 16
d--xrwx--x   3 nobody   sgml         4096 Mar 18 16:45 .
drwxr-xr-x  23 root     root         4096 Mar 18 03:07 ..
drwxr-xr-x   2 sgml     sgml         4096 Mar 18 16:45 New Folder
-rwxrw-r--   1 sgml     sgml            0 Mar 18 16:44 newtextfile.txt
----rw----   1 nobody   sgml            5 Mar 18 16:29 test3.txt

The sgml.sgml creation is fine and expected, I have a script which will mop it
up and chown it to nobody overnight. The above is expected behavior. But 
remember that read-only file? I can rename the bugger!!! Yup, I'm asked by 
windows if I really want to rename this read-only file, and when I say yes, 
viola:

[root at ducent /test]# ls -al
total 16
d--xrwx--x   3 nobody   sgml         4096 Mar 18 16:48 .
drwxr-xr-x  23 root     root         4096 Mar 18 03:07 ..
drwxr-xr-x   2 sgml     sgml         4096 Mar 18 16:45 New Folder
-rwxrw-r--   1 sgml     sgml            0 Mar 18 16:44 newtextfile.txt
----rw----   1 nobody   sgml            5 Mar 18 16:29 renamed test3.txt

and Samba reports no locked files.


I have the feeling I'm overlooking something pretty fundamental here. Can 
anyone tell me what it is?

Thanks!

-Darren