Samba 3.6.x on RHEL 6 - secondary group and sgid problem

Latest response

I recently moved some samba services from a RHEL 5.x server to a RHEL 6.x server and I have noticed that we now have a problem with write permissions in filesystem directories that are controlled by secondary group membership (and the sgid bit). What has worked as expected with Samba version 3.0.33-3.40.el5_10 on RHEL 5.x is now broken with Samba version 3.6.23-24.el6_7 on RHEL 6.x. It seems that the more recent samba server is not recognising/using secondary groups that a user is a member of and so is failing to write to the filesystem even though Unix permissions for the user allow it.

The share definitions are pretty simple, eg

[project]
path = /project
browseable = no
writable = yes
create mode = 0664
directory mode = 0775

And the samba servers are set for security = user. The same configuration and share definition is used on RHEL 5.x and RHEL 6.x servers.

On the server side, a project subdirectory is made with sgid to a secondary group (and write permission for that group).

drwxrwsr-x 2 root group2 4096 May 20 10:01 test/

The user is in group2 and can create files in the test subdirectory when logged in to the servers. New files inherit the group2 gid as expected.

When the user has mapped to the share from a samba 3.0.x server, Windows clients can create files without problem.

But when mapped to the share from a samba 3.6.x server there is a permission problem. The service does not allow writing to the directory - even though writing is permitted by the user's group membership on the server.

Eg, here are the Windows NET USE drive mappings from a client (one each to 5.x and 6.x servers):

V: \\c5server\project\ISO
X: \\c6server\project\ISO

Works with RHEL 5.x server

V:\test>date /t > c5.txt

Does not work with RHEL 6.x server

X:\test>date /t > c6.txt
Access is denied.

On the 6.x server if I then change the user ownership of the test directory to the authenticated user then writing via the mapped drive is allowed. That's because the owner and not group permission is being matched in that case.

But for shared project directories among several different sets of users I do depend on group and not owner permissions to be used to control write access! Not having this work with Samba 3.6.x on RHEL 6.x is a bit of a problem.

Has anyone else noticed this issue? If so are there options to correct the behaviour?

(I have found that setting security = share does allow secondary group membership to be honored on the server side, but that option is deprecated and security = user is what I would like to use - if only samba 3.6.x would handle sgid directories owned by secondary groups!

--
Roger

RW

Responses