[Samba] Users cannot rename, delete files on AD-member Samba server

[Goldschrafe, Jeffrey]

Hi there!

I'm having some strange permissions issues with one of my systems that's
on an Active Directory domain.

Here's the basic background:

 - System is joined to AD domain. Users authenticate fine via Kerberos,
and are authorized via an AD user group. They can browse the share,
create files, etc. without incident. "valid users" lets them in.
 - User information for the system (nsswitch) comes out of LDAP. The
LDAP is non-AD (a legacy OpenLDAP setup), but the usernames all line up
and Samba can resolve each user's UID/GID and secondary groups without a
problem.
 - The share is semantically owned by a single Unix group.
 - That security group is mapped in "net groupmap" to a Unix group. I'm
not entirely sure if this is actually necessary.
 - Share has "force create mode = 0664" and "force directory mode =
0775" to ensure that files are writable by the group by default.

When a user connects to the share using a Windows client (XP or Vista),
they are unable to rename folders, and unable to rename or delete files.
They are able to delete folders, as long as the folders do not contain
any files. This means that when using Explorer to create a file or
folder, it can be created with the default name (e.g. "New Folder" or
"New Text Document.txt") but any attempt to assign a
semantically-meaningful name will fail with an "access denied" error.
This applies to renaming existing files as well, of course.

When the same user connects from a Mac or Linux client, through Finder,
Dolphin or smbclient, the same exact operations work. The user can
rename and delete just fine as long as it isn't from Windows.

Additionally:

 - When the file is created from Windows, it has the correct permissions
on the server.
 - If a file is created from a Mac or Linux client, or locally on the
server, it cannot be deleted or renamed from a Windows client.
 - If a file is created from a Windows client, it can be renamed or
deleted from a Mac or Linux client without issue.

The following things make the operations work on Windows:

 - Adding the users or groups to the "admin users" attribute for the
share.
 - Setting "force group" to be the group that owns the share directory
on the filesystem.

The fact that "force group" makes this work implies that there may be
some kind of problem resolving the group membership, but only for
Windows clients. This doesn't really make a lot of sense to me, so it's
just wild speculation on my part about where the problem actually is.

Any ideas?

Jeff Goldschrafe <goldschr at cshl.edu>
Systems Engineer
Cold Spring Harbor Laboratory
1 Bungtown Road
Cold Spring Harbor, NY 11724
http://www.cshl.edu