Michael Anderson wrote:
Aha! After 'c)' above, things are looking better:


when I copy a file from the CIFS share to the windows desktop, the user's unix GID disappears from the permissions, and the 'SYSTEM' group appears instead.

I believe that most Windows copy programs do not attempt to preserve the ACL.

If create a file on Windows, there exist windows permissions for the user and SYSTEM, the unix group is 'nobody', and the unix owner is no longer owner, but a generic user with certain ACL rights to the file and can read, write, but not delete files. So the perms look like this on opensolaris:

# ls -vl created_on_windows.txt
----------+ 1 vuser1 2147524611 0 Mai 26 00:03 created_on_windows.txt 0:user:vuser1:read_data/write_data/append_data/read_xattr/write_xattr

You might want to add "ad" to your /etc/nsswitch.conf passwd and group lines, so that ls -l can show you the Windows users and groups instead of the big numbers like 2147524611. See ad(5).

You might try
   $ idmap show -cv gid:2147524611 winname
to confirm what the group setting is on that file. (Probably the answer is Domain Users.)

I suppose I have to walk the share with inheritable 'owner@' permissions, or something like that?

That might help ls -l produce good-looking permission values. It also depends on what semantics you want: do you want the access control to apply to the current owner of the file (which is usual UNIX behavior) or do you want it to apply to some specific user (which is usual Windows behavior)?

There are two recent CRs that are relevant to this behavior:

6899409 Preserve owner@/group@ across SMB

UNIX has a concept of an access control entry (the rwx------ bits in traditional UNIX) that applies to the current owner of a file, whoever that might be. Windows doesn't have this concept. Before build 132, for Windows purposes we would translate the "owner" permissions into an access control entry that specified the current owner of the file. That looked pretty much right, but caused a problem: if the Windows system wrote that access control list back to the server, the effect would be to change that access control entry from "the current owner" to some specific user, changing its semantics. (Automatically converting it back to a "current owner" entry would cause a similar problem.) Starting in build 132, we report a special "Current owner" user to Windows, so that the semantics are preserved when the Windows system makes changes. (Similar comments apply to "current group".)

6923083 ZFS/NFS/SMB ACL interoperability changes

In ZFS, all access control is through access control lists. There are no traditional UNIX permissions stored; UNIX permissions are synthesized when needed by processing the access control lists. Before build 139, that algorithm considered only "current owner" and "current group" entries when synthesizing traditional UNIX permissions. That often resulted in permissions that looked like "---------" even when the owner of the file had full access, because that access was granted explicitly to that user rather than to "the current owner". Starting in build 139, access control entries that refer specifically to the user who happens to own the file are also considered. Note: Since the actual access control checks use the access control list, these "bad" permissions reports largely did not affect access; they just worried humans looking at them. (Again, similar comments apply to "current group".)

Note that these two can combine to turn a "current owner" access control entry into a specific-user entry, and thus yield a "---------" permission list.

But how do I make newly created files belong to the unix primary group?

To which UNIX primary group do you refer?

They probably belong to the Windows primary group of the Windows user.

Perhaps you want them to belong to the UNIX primary group of the UNIX user?

That is:

If you have
- a UNIX user UU, whose primary group is UG1
- a Windows user WU, whose primary group is WG
- WU is mapped to UU
- WG is mapped to UG2

Before build 137, if WU creates a file, we consider the user and group separately, mapping WU to UU and WG to UG2. The file thus ends up with owner=UU and group=UG2.

That's not unreasonable, but it's probably not what a UNIX-centric user expects, because it's not what you would have gotten if UU created the file. CR 6906874 "Automatic primary group mapping based on user mapping", delivered in build 137, changes this behavior. With the new behavior, for the purposes of the group setting of newly created files and directories, we use the UNIX user's primary group - UG1 in this case. (It's not relevant here, but we continue to use WG and thus UG2 when processing the Windows-style CREATOR GROUP access control list entry, since that's what a Windows-centric user would expect.)

Note that Windows-centric users are unlikely to care about the file's group setting, and UNIX-centric users are unlikely to care about the behavior of CREATOR GROUP.

Does that all make sense?

Thanks again for all the help,

My pleasure.

cifs-discuss mailing list

Reply via email to