samba - Mar 2000 - Samba file access by GID - what am I missing???

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@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@ducent /test]# su sgml
[sgml@ducent /test]$ id
uid=503(sgml) gid=700(sgml) groups=700(sgml)
[sgml@ducent /test]$ ls -l test3.txt 
----rw----   1 nobody   sgml            0 Mar 18 13:44 test3.txt
[sgml@ducent /test]$ touch test3.txt 
[sgml@ducent /test]$ ls -l test3.txt 
----rw----   1 nobody   sgml            0 Mar 18 16:29 test3.txt
[sgml@ducent /test]$ echo "test" > test3.txt 
[sgml@ducent /test]$ ls -l test3.txt 
----rw----   1 nobody   sgml            5 Mar 18 16:29 test3.txt
[sgml@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@ducent /test]# egrep sgml /etc/passwd
sgml:x:503:700::/home/sgml:/bin/bash
[root@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@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@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

[Darren Nickerson]
> 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:
Make sure the file isn't owned by you.  Ownership permissions override
group permissions, so ----rw---- means the owner has no access.
> 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:
Learn about Unix file permissions.  You can rename or delete a file as
long as you have write permission to the directory it is in.  (The
exception: if the directory has its sticky bit (--------t) set, you can
only rename or delete files that belong to you.  This helps prevent
people from screwing with each other in /tmp.)

This is fairly unintuitive for many people new to Unix, and is quite
different from how most other operating systems do things.  (The reason
for these semantics has to do with the Unix paradigm for what a file
actually is.  It's *not* a directory entry.  In most non-Unix operating
systems, a file and a directory entry are seen as pretty much the same
thing.)

Peter