[Samba] Setting permissions on AD member file server

Tue Mar 15 13:58:00 UTC 2022

On 3/14/22 17:41, Gregory Sloop via samba wrote:
> I've had a little time to tinker and one thing I've found.
>   
> Unless I have [acl_xattr:ignore system acls = yes] set, I can't edit permissions at all.
> (I set it globally, though a share level setting would probably work on a per-share basis.)

There must be another issue here.  I have:

    vfs objects = acl_xattr
    map acl inherit = yes
    store dos attributes = yes

set in smb.conf and most certainly can edit permissions from Windows, 
although this has also failed in some cases for reasons I haven't been 
able to pinpoint (but am guessing is related to the long path issue).

>   
> This seems to be a quasi-sideeffect of that setting  - in short that setting overwrites/resets the posix permissions. (Provided I understand discussions I've seen about it.)
>   
> In this case the share will only be used by Windows users via CIFS/Samba - so this may well "work" just fine and as a happy side-effect, make the problem vanish.
> But I'd guess it's not really the "correct" fix.
>   
> To that end, what would be the best way to reset the permissions on the directories/files properly, removing all the Samba ACL's etc? Once they are set as a baseline in POSIX then we can tinker with Samba ACL's with the Windows permissions again. (And remove acl_xattr:ignore system acls = yes)

Adding on to this, I would like to completely reset all the Windows 
permissions, since the filesystem permissions look good, but resetting 
permissions on some folders fails from Windows.  If Windows 10 File 
Explorer does not support long paths, then how would someone use this to 
reset permissions on deeply nested folders anyway?  I've determined that 
at after a certain path length the security tab disappears from 
Properties completely!

>   
> Rowland?
>   
> (I'm not making any claims about "Administrators" vs "Domain Admins" and permissions in this post. I'm simply trying to deduce what's going on, and talk about a single thing that make it work differently, perhaps more or less inadvertently.)
>   
>    
> 
>> On 12 March 2022 09:22 Rowland Penny wrote:
> 
>>> On Fri, 2022-03-11 at 22:48 +0000, spindles seven via samba wrote:
> 
>>>> On 11 March 2022 22:26 Rowland Penny wrote:
> 
>>>>> I take it you found that out from here:
> 
>>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.samba.org%2Findex.php%2FSetting_up_a_Share_Using_Windows_AC&data=04%7C01%7C%7C4d95fe15883b49b0a63f08da060bdcf2%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C0%7C0%7C637828945295088796%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3AGGfZStDR21zNigyhb8prAhQLX2o96tlckw6Lzg%2FGs%3D&reserved=0
>>>>> Ls#Addi
>>>>> ng_a_Share
> 
>>>> Yes indeed.
>>>>> That is what I was getting at, it used to work. A member of Domain
>>>>> Admins logged into Windows could change the permissions on a share,
>>>>> provided everything was set up correctly on the Unix domain member.
>>>>> I can now only do this with Administrator.
> 
>>>>> Rowland
>>>> works for me (on version 4.15.5), so what's different?
>>> I am using 4.15.5 and it doesn't work for me, it used to, but it doesn't any longer.
> 
>>> Rowland
>> OK, so using a test installation of Debian Bullseye in a VM and Samba 4.15.5, I left the domain and cleaned up the samba database files as per the WiKi.   I deleted the existing folders ie /srv/samba and all sub folders.     Using that same page in the WiKi (https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.samba.org%2Findex.php%2FSetting_up_Samba_as_a_Domain_Member&data=04%7C01%7C%7C4d95fe15883b49b0a63f08da060bdcf2%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C0%7C0%7C637828945295088796%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=u1XD73sQR%2Funckq8eRGjulNPWr2KSsjmpSHX0AWYBxs%3D&reserved=0) I joined the domain.    This is the smb.conf at that stage:
> 
>> [global]
> 
>>          security = ADS
>>          workgroup = MICROLYNX
>>          realm = MICROLYNX.ORG
> 
>>          log file = /var/log/samba/%m.log
>>          log level = 1
> 
>>          winbind use default domain = yes
> 
>>          # Default idmap config used for BUILTIN and local accounts/groups
>>          idmap config *:backend = tdb
>>          idmap config *:range = 2000-9999
> 
>>          # idmap config for domain MICROLYNX
>>          idmap config MICROLYNX:backend = rid
>>          idmap config MICROLYNX:range = 10000-99999
> 
>>          # next two lines for testing only - comment-out once working ok
>>          winbind enum users = yes
>>          winbind enum groups = yes
> 
>>          template shell = /bin/bash
>>          template homedir = /srv/samba/users/%U
> 
>>          vfs objects = acl_xattr
>>          map acl inherit = yes
>>          username map = /etc/samba/user.map
> 
>>          # allow administrator to access having been mapped to root (uid 0)
>>          min domain uid = 0
>> ==========
>> I then added shares [users] and [test] as follows:
> 
>> [users]
>>          # user homedirs
>>          path = /srv/samba/users
>>          read only = no
>>          acl_xattr:ignore system acls = yes
> 
>> [test]
>>          path = /srv/samba/test
>>          read only = no
> 
>> I set the Unix permissions as follows:
>> chown root:"Domain Admins" /srv/samba/users
>> chown root:"Domain Admins" /srv/samba/test
>> chmod 0770 /srv/samba/users
>> chmod 0770 /srv/samba/test
> 
>> I granted Domain Admins the SeDiskOperatorPrivilege on the test server then attempted to set the permissions from Windows using the WiKi page: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.samba.org%2Findex.php%2FSetting_up_a_Share_Using_Windows_ACLs&data=04%7C01%7C%7C4d95fe15883b49b0a63f08da060bdcf2%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C0%7C0%7C637828945295088796%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2FzGeiwpIaVY2Wlq57jl8xCiX6xBi7XZ%2BA9oH1Oqj7lA%3D&reserved=0
> 
>> I logged onto Windows 10 using a user who is a member of Domain Admins and was able to set permissions correctly using Computer Management on the [test] share, but not on the [users] share;   to allow the permissions to be applied from windows initially, I had to temporarily comment out the "acl_xattr:ignore system acls = yes" line and reload the smb config.  Once set, I removed the comment (#) from that line.
> 
>> On the Users share I set:
>> Domain Admins   Full Control            This folder only
>> CREATOR OWNER   Full Control            Subfolders and files only
>> SYSTEM  Full Control            This folder, subfolders and files
>> Authenticated Users     Special*        This folder only
> 
>> * Traverse folder/execute file, List folder/read data, Read attributes, Read extended attributes, Create folders/append data, Read permissions
> 
>> The folder looks like this as seen from Linux:
>> root at m2test:~# ls -l /srv/samba
>> total 16
>> drwxrwx---+ 2 root domain admins 4096 Mar 13 11:47 test
>> drwxrwx---+ 2 root domain admins 4096 Mar 13 11:47 users
>> root at m2test:~# getfacl /srv/samba/users
>> getfacl: Removing leading '/' from absolute path names
>> # file: srv/samba/users
>> # owner: root
>> # group: domain\040admins
>> user::rwx
>> user:root:rwx
>> user:domain\040admins:rwx
>> group::rwx
>> group:NT\040Authority\\authenticated\040users:rwx
>> group:NT\040Authority\\system:rwx
>> group:domain\040admins:rwx
>> mask::rwx
>> other::---
>> default:user::rwx
>> default:user:root:rwx
>> default:group::---
>> default:group:NT\040Authority\\system:rwx
>> default:group:domain\040admins:---
>> default:mask::rwx
>> default:other::---
> 
>> So following the WiKi as close as possible, I am able to set permissions using a Domain Admins account, not sure why your system is preventing you?
> 
>> Thanks for your invaluable help as always.
> 
>> Roy
> 