Samba Mystery: Users with Group permissions get denied based on Other.
 

Crazy issue to try to explain. And, I've got a wealth of details I could give--been working over this one for months.

I'll start with the user's perspective:

Windows XP User opens Excel. Save As.
Chooses a samba share (where user is in group that has rwx). Click's Save.
File appears with the specified name.
Window shows "The file {blah} exists. Do you want to replace the existing file?" (File name didn't exist before attempting this save.)
Choosing Yes -> File fsa727.tmp appears. (repeats will increment #)
-> Window says "Cannot save {full path}. Folder is marked 'Read Only'." Clicking OK drops back to save window.
Choosing No -> Drops back to save window (no .tmp created).

Opens Word. Save As.
Chooses same samba share.
File appears with the specified name.
File ~${name of file}.doc appears.
File ~WRD0000.tmp appears.
File ~WRD0001.tmp appears.
All files cannot be renamed/deleted (including the properly named file). "Access is denied."

Creates any kind of file (right-click -> new) in the samba share. Can not rename/delete. Access is denied.

Ok, now for some admin-side info.

*Many users in the same group (and only that group) have no trouble. Newly created users seem to always have it, though.
*Interaction with created files by a user in a different group that has access (via ACL's) is normal--can delete/rename/etc. That same user can also create files in the same directory normally.
*The files that are apparently "read only" to the broken user are created with ownership {nameOfUser}:{nameOfUser'sGroup} and permissions 770.

There you have it and there you are. I'll appreciate any and all attempts to solve this mystery. (Sorry this isn't Treasure Quest, and I'm not Sirius.) ;) As it is when this happens, I'm creating new groups and adding broken users into them and giving the new group ownership via ACL.

PS A recent development. The most recent share to have a "broken user" on it also has "Segmentation fault" when I try to getfacl the folder. None previous have had this symptom, however.

Oops... one more thing. The screwed up files are 0-byte. My guess so far is that the "file saving process" somehow switches to "Other" permissions just after the initial file creation but before the temporary "just typed up" file can overwrite it. Bizarre, no?

Another piece of the puzzle...
 

Maybe even an outside piece. ;)

User with issue attempts to rename a file. (Giving, of course, Access Denied).
A look at the logs (level 3) for that computer shows one "fetch sid from gid". One that matches a group that the member is apart of that *doesn't* have access.

Let me clarify the setup:

share z <- The problem share
Group 1 <- Has rwx to z
Group 2 <- Has no permissions set for z
User A <- Is in 1 and 2

Does anyone have any idea why it would be {seemingly *only*} trying the wrong group?

I'll throw this slightly important piece of info in now: samba-3.0.30-0.fc7

*goes off to hide in a closet with the samba HOWTO/Reference Manual*

Wireshark
 

* continues intrapersonal discussion *

I wiresharked the saving process. Now... if I only knew what all this stuff meant. >< Here's what I do know. Thousands (literally) of "NT Create AndX Resquests"/"Response" packets. Responses all coming back status access denied. I was hoping to be able to see if the packets going out from the client were sending the errant authorization. No luck finding group membership, etc info in the packets.

Still in the dark about how Samba determines access rights. Is it more like "user: try every key on your keychain"? Or, "file: who can access you?" Samba reference manual didn't turn up any answers. So, still not sure if I need to be looking for this mistake to on the client/samba server/AD server.

Guess I'll go back to the logs and venture past level 3.

What are your share definitions?
 

Samba gives you the option of defining the per-share access levels through the use of force user/group and in-/valid users in the share definitions--instead of through ACL's directly on the folders being shared. But doing them both ways at the same time can lead to some pretty mysterious behavior.

Good call!
 

Well, I don't really understand how it's causing the bizzare situation I'm in.... but apparently you're right. The share did have the "force group" set to the (from the above example) Group 2. So, even though the ACL's said Group 1 has access to the files, some of the individual processes were being blocked by the "forced group's" lack of permissions (while some, like the initial file creation, weren't).

Funny thing is, many of the shares defined on this server have a similar setup. The force group is a low-clearance group while the folders themselves allow for higher access for specific groups. Yet, of all the different combinations of users/groups/share/ACLs that have this same setup... only about 1% of them experience the problem I'm seeing. (And those 1% do so every time without fail.) So, it seems like there must be one other unknown factor causing this problem. Anyway, the important this is....


RESOLUTION: Removed "Force group" setting from share definition. Problem went away.

Thanks for all your help guys! :D

Curiosity killed the cat...
 

...and by "the cat" i mean "today's other responsibilities".

I haven't been able to let this go just yet. What was the real problem. The solution that worked for me (commenting out the "force group") circumvented a problem that some users had--but others with the same group membership didn't have. Here's the results of today's Wireshark investigation:

Same user/same computer/same saving Excel blank file process:
Broke (force group enabled)-- SMB packet's source port on client=1125
Working(commented force group) -- SMB packet's source port on client =1677

???

The difference in port also seems to have some compounding effects seen in later packets. The second 'NT Create AndX Request' (that attempts to open the file--the first attempts to create it) doesn't have an FID when it's broke, does when it's working. Also, the broke version has several 'NT Trans Requests/Responses' while the working version has no such packets. (The NT Trans packets functions are all "NT NOTIFY" with the exception of two responses that come back with "<unknown function - couldn't find matching request>".)

Additional info
 

Hi I had the same problem (or similar behaviour at least) with being able to create New Folders but not being able to rename them.

I tried removing the 'force user' / 'force group' directives but that didn't work for me.
I had a line saying 'profile acls = yes' which I commented out which fixed this problem for me.

Thanks for the info Emiro.

Misdirection...
 

The ports don't seem to be the source of the trouble. Tried a few more captures on successful saves/renames. Port used from the client changes without negative effects. Wish I knew how to see exactly what's happening in the permission determination process.

It may be awhile before I can devote more time to this issues (unless someone comes up with some advice/guidance for me), but if I come back to this issue, I'll be sure to keep this thread updated.