[Samba] Remove all Windows ACL's from files/folders

[Rowland Penny]

On Tue, 2022-03-29 at 10:40 -0700, Greg Sloop <gregs--- via samba
wrote:
> Sorry for the long post;
> The gist is:
> 
> 1) I set permissions in the Windows UI, and it appears to be
> successful.
> 2) I then attempt to access a share, from a domain joined Windows PC,
> using
> the user (and group) I've assigned "full control" to.
> 3) It Fails.
> 4) So, I check the Samba logs - sure enough it shows that user
> attempting
> to access that share.
> 5) I check to be sure the UID matches the UID of the user. It does.
> 6) I check the GID and it also matches.
> 7) I check the NTACL perms that Samba thinks are set, and look (as
> best I
> can understand) the SDDL output.
> 8) And the SDDL output doesn't even remotely match the permissions I
> set in
> Windows.
> 
> And I have no idea where to look next to figure out why.
> 
> Following is the "show my work" section. :)
> ---
> 
> So, I'm only able to set permissions (as Administrator) with
> "acl_xattr:ignore system acls = yes" set.
> (Which is "wrong" but lets just go with it. You'll see where I'm
> going in a
> minute.)
> 
> So, I set the permissions on a share to the following. (From the
> Windows
> file explorer)
> Allow root: full control
> Allow SYSTEM: full control
> Allow Domain Admins: full control
> Allow: Domain Users: full control
> Allow ad\gs: full control
> 
> I'm testing with a test user, AD\GS.
> GS is a member of domain users, which should grant access, but
> doesn't.
> So, I add the user explicitly, which also fails to grant access.
> 
> So, check the Samba logs.
> ---
> 2022/03/29 10:23:54.736440,  0]
> ../../source3/smbd/service.c:168(chdir_current_service)
>   chdir_current_service:
> vfs_ChDir(/abc-zfs-01/ad-shared-folders/shared-files) failed:
> Permission
> denied. Current token: uid=11608, gid=10513, 7 groups: 11608 10513
> 11129
> 3003 3004 3006 3001
> ---
> # wbinfo -i "ad\gs"
> AD\gs:*:11608:10513:gs:/home/AD/gs:/bin/false
> ---
> 
> So the UID in the Samba log matches the user I expect.
> That's good.
> At least the user attempting access matches the user I've set
> permissions
> for,
> 
> ---
> Incidentally, the group matches too;
> wbinfo -i "ad\domain users"
> AD\domain users:*:10513:10513::/home/AD/domain users:/bin/false

I have been a bit busy with other things, but I had a quick look at
this and the above stands out. If you can run 'wbinfo -i' against a
group and get that output, then you have problems somewhere. '-i' is
short for '--user-info' and 'Domain Users' isn't a user, you need to
run: wbinfo --group-info="AD\domain users"

Rowland