Microsoft's default behavior is to assign "Administrators" as the owner of any file or folder when that file or folder is created with an administrative account (Any member of Administrators). In an AD environment, this includes the "Domain Admins" group and all of its members too because any time a computer account is joined to the domain, one of the things that happens during this process is to add "Domain Admins" to the local computer's Administrator's group. (Source: https://technet.microsoft.com/en-us/library/cc961992.aspx) This behavior is the reason why we have a large number of files and folders that are owned by that builtin\Administrators group. Samba, while happy to replace mapped group ID's with user ID's when assigning ownership of non-builtin groups, refuses to do so for the builtin groups, but it's not clear why. Example of AD groups being assigned as owner working: "getent group 'DOMAIN\Domain Admins'" returns: DOMAIN\domain admins:x:20512:(along with all the users that are member of this group.) Yet, even though getent sees this is a group, I can use this id for the owner of a folder: chown "DOMAIN\Domain Admins" CoreLib/ ls -lnd CoreLib/ d---------+ 2 20512 90000001 5 Dec 8 11:59 CoreLib// If I do a reverse lookup of the numeric id as both a user or group, I see why this works: id -u 'DOMAIN\Domain Admins' 20512 id -g 'DOMAIN\Domain Admins' 20512 chown is not using the group id, it's using a user id that's the same as the group id. I assume Samba does this slight of hand because Windows doesn't differentiate between users and groups the way that nix does. So lets try with BUILTIN\Administrators instead: "getent group 'BUILTIN\Administrators'" returns this: BUILTIN\administrators:x:90000001 However, doing a reverse lookup shows the problem: id -u 'BUILTIN\administrators' id: BUILTIN\administrators: no such user id -g 'BUILTIN\administrators' BUILTIN\administrators:x:90000001 So while the system is perfectly fine assigning "DOMAIN\Domain Admins' as both an owner and a group: chgrp 'DOMAIN\Domain Admins' CoreLib/ ls -lnd CoreLib/ d---rwx---+ 2 20512 20512 5 Dec 8 11:59 CoreLib// ls -lad CoreLib/ d---rwx---+ 2 DOMAIN\domain admins DOMAIN\domain admins 5 Dec 8 11:59 CoreLib// The same is impossible because there is no mirrored BUILTIN\administrators user id internal to Samba. This breaks the behavior Microsoft documented in that URL above.
I'm pretty sure this works if you use a idmap backend that supports ID_TYPE_BOTH. Currently this is only supported by the "rid", "autorid" and "script" (if the script supports it) on a member or standalone server. It should always work on an active directory domain controller.
(In reply to Stefan Metzmacher from comment #1) What idmap configuration are you using?
It's the default setup used by the FreeNAS folks. I looked for help from the FreeNAS community first, but they were out of ideas: https://forums.freenas.org/index.php?threads/ownership-issues-migrating-data-from-windows-to-freenas.41478/ I then tried the samba list server, but Andrew just said I couldn't because "sysvol." When I asked for additional details, he never responded: https://lists.samba.org/archive/samba/2016-February/197771.html [global] server max protocol = SMB2 encrypt passwords = yes dns proxy = no strict locking = no oplocks = yes deadtime = 15 max log size = 51200 max open files = 942185 load printers = no printing = bsd printcap name = /dev/null disable spoolss = yes getwd cache = yes guest account = nobody map to guest = Bad User obey pam restrictions = yes directory name cache size = 0 kernel change notify = no panic action = /usr/local/libexec/samba/samba-backtrace nsupdate command = /usr/local/bin/samba-nsupdate -g server string = FreeNAS Server ea support = yes store dos attributes = yes lm announce = yes hostname lookups = yes acl allow execute always = true acl check permissions = true dos filemode = yes multicast dns register = yes domain logons = no idmap config *: backend = tdb idmap config *: range = 90000001-100000000 server role = member server netbios name = FREENAS workgroup = DOMAIN realm = INTRANET.DOMAIN.COM security = ADS client use spnego = yes cache directory = /var/tmp/.cache/.samba local master = no domain master = no preferred master = no ads dns update = yes winbind cache time = 7200 winbind offline logon = yes winbind enum users = yes winbind enum groups = yes winbind nested groups = yes winbind use default domain = no winbind refresh tickets = yes idmap config DOMAIN: backend = rid idmap config DOMAIN: range = 20000-90000000 allow trusted domains = no client ldap sasl wrapping = plain template shell = /bin/sh template homedir = /home/%D/%U pid directory = /var/run/samba create mask = 0666 directory mask = 0777 client ntlmv2 auth = yes dos charset = CP437 unix charset = UTF-8 log level = 1 [shared] path = /mnt/trunk/MM/shared printable = no veto files = /.snapshot/.windows/.mac/.zfs/ writeable = yes browseable = yes shadow:snapdir = .zfs/snapshot shadow:sort = desc shadow:localtime = yes shadow:format = auto-%Y%m%d.%H%M-1w shadow:snapdirseverywhere = yes vfs objects = shadow_copy2 zfs_space zfsacl aio_pthread streams_xattr hide dot files = yes guest ok = no nfs4:mode = special nfs4:acedup = merge nfs4:chown = true zfsacl:acesort = dontcare
It looks like I can drop-n replace tdb with autorid? Leave all the other numbers the same? As far as I know, we'd only use that configuration for non AD accounts, so really, just BUILTIN\*
(In reply to Ian from comment #4) yes, or: idmap config BUILTIN: backend = rid idmap config BUILTIN: range = 100000000-110000000 If this is a new installation just using autorid as default and no per DOMAIN config: idmap config *: backend = autorid idmap config *: range = 20000-100000000
Here's my idmap setup now (I incremented the number range you gave so that there wouldn't be any overlap): idmap config *: backend = tdb idmap config *: range = 90000001-100000000 idmap config DOMAIN: backend = rid idmap config DOMAIN: range = 20000-90000000 idmap config BUILTIN: backend = rid idmap config BUILTIN: range = 100000001-110000000 However, I'm still not able to change the owner, and now it seems I can't even lookup the group id: id -u 'BUILTIN\Administrators' id: BUILTIN\Administrators: no such user id -g 'BUILTIN\Administrators' id: BUILTIN\Administrators: no such user getent group 'BUILTIN\Administrators' BUILTIN\administrators:x:90000001 chown 'BUILTIN\Administrators' CoreLib/ chown: BUILTIN\Administrators: illegal user name
I noticed that gentent is still returning an id from the TDB backend: getent group 'BUILTIN\Administrators' BUILTIN\administrators:x:90000001 Is this a cache issue? I tried renaming the winbindd_cache.tb file and restarting the service, but that didn't help so I put it back. Here's the contents of my /var/db/samba4 folder: -r-------- 1 root wheel 0 Jan 4 11:38 .usersimported -rw------- 1 root wheel 421888 Feb 7 18:13 account_policy.tdb -rw-r--r-- 1 root wheel 40200 Feb 26 09:22 brlock.tdb -rw------- 1 root wheel 696 Feb 26 09:22 dbwrap_watchers.tdb -rw-r--r-- 1 root wheel 696 Jul 27 2015 gencache.tdb -rw-r--r-- 1 root wheel 430080 Feb 26 09:23 gencache_notrans.tdb -rw------- 1 root wheel 425984 Jul 27 2015 group_mapping.tdb -rw-r--r-- 1 root wheel 86016 Feb 26 09:23 locking.tdb -rw------- 1 root wheel 16384 Feb 26 09:23 messages.tdb -rw------- 1 root wheel 696 Feb 26 09:23 mutex.tdb -rw-r--r-- 1 root wheel 3473 Feb 22 14:56 namelist.debug -rw-r--r-- 1 root wheel 12288 Feb 26 09:23 notify.tdb -rw-r--r-- 1 root wheel 8192 Feb 26 09:23 notify_index.tdb -rw-r--r-- 1 root wheel 12288 Feb 22 14:56 printer_list.tdb drwx------ 2 root wheel 6 Feb 26 09:22 private/ -rw------- 1 root wheel 528384 Jul 27 2015 registry.tdb -rw-r--r-- 1 root wheel 8192 Feb 26 09:23 serverid.tdb -rw------- 1 root wheel 421888 Jul 27 2015 share_info.tdb -rw------- 1 root wheel 28672 Feb 26 09:23 smbXsrv_open_global.tdb -rw------- 1 root wheel 36864 Feb 26 09:23 smbXsrv_session_global.tdb -rw------- 1 root wheel 16384 Feb 26 09:23 smbXsrv_tcon_global.tdb -rw------- 1 root wheel 16384 Feb 26 09:23 smbXsrv_version_global.tdb drwxr-xr-x 2 root wheel 3 Feb 26 09:23 smb_krb5/ -rw------- 1 root wheel 2527232 Feb 26 09:23 winbindd_cache.tdb -rw------- 1 root wheel 630784 Feb 26 09:22 winbindd_cache.tdb.bak -rw------- 1 root wheel 28672 Feb 26 09:21 winbindd_cache.tdb.bak.old -rw-r--r-- 1 root wheel 421888 Sep 9 06:49 winbindd_idmap.tdb drwxr-x--- 2 root wheel 3 Feb 26 09:22 winbindd_privileged/
Stephan, Is there anything more I can do here for you? Can you confirm that it is indeed possible to assign builtin\groups as owners using backends with ID_TYPE_BOTH? Also, isn't it still considered a bug if tdb doesn't support this? I mean if Samba isn't performing like a similarly configured Windows machine, should that be considered a bug?
(In reply to Ian from comment #8) Implementing this for the tdb backend would be nice, but it's more a missing feaeture than a bug