On 11/20/21 4:25 AM, Rowland Penny via samba wrote:> On Fri, 2021-11-19 at 19:00 -0500, Ken Bass via samba wrote:
>>>
>> Hi Rowland,
>>
>> On the SERVER side:
>>
>> -rwxrwx---+ 1 user testshare users 16 Nov 19 16:11 test.txt
> Yes, you are using ACL's, note the '+' at the end of the Unix
> permissions.
>
> What does 'getfacl test.txt' produce ?
>
>> On the CLIENT side, where this share is mounted via cifs in
>> /etc/fstab
>>
>> -rwxrw---- 1 user testshare users 16 Nov 19 16:11 test.txt
> However, the cifs mounted share doesn't seem to be using using
ACL's
It has cifsacl in the /etc/fstab, so I don't know why.
>> And reproducing the issue - on the CLIENT side
>>
>> /usr/bin/getcifsacl test.txt
>> REVISION:0x1
>> CONTROL:0x8004
>> OWNER:MYDOM\user
>> GROUP:MYDOM\Testshare Users
>> ACL:MYDOM\user:ALLOWED/0x0/FULL
>> ACL:MYDOM\Testshare Users:ALLOWED/0x0/FULL
>> ACL:\Everyone:ALLOWED/0x0/
>>
>> And after running
>>
>> chmod u-x test.txt
> I wouldn't recommend running chmod against anything that has an ACL set
> on it, it will probably remove or change the ACL.
I personally am not running chmod other than for troubleshooting, but
the Linux application that writes to the files on the share clears that
execute bit when it updates/modifies files.
So I am stuck with that.
>> -rw-rw---- 1 user testshare users 16 Nov 19 16:12 test.txt
>>
>> /usr/bin/getcifsacl test.txt
>> REVISION:0x1
>> CONTROL:0x8004
>> OWNER:MYDOM\user
>> GROUP:MYDOM\Testshare Users
>> ACL:MYDOM\user:DENIED/0x0/0xd0130
>> ACL:MYDOM\user:ALLOWED/0x0/0x1f01df
>> ACL:MYDOM\Testshare Users:ALLOWED/0x0/FULL
>> ACL:\Everyone:ALLOWED/0x0/0x40
>>
>> Notice after running the chmod to remove the user exec permission,
>> the
>> DENIED ACL is added.
>>
>> That DENIED ACL does not just remove 'execution', but as I
>> originally
>> posted:
>>
>> test.txt MYDOM\user:(DENY)(D,WDAC,WO,WEA,X,WA)
>> MYDOM\user:(R,W,D,WDAC,WO,DC)
>> MYDOM\Testshare Users:(F)
>> Everyone:(DC)
>>
>> it appears to also remove WEA - Write extended attributes, WA -
>> Write
>> attributes, WO - Write owner.
>>
>> My guess is that is why trying to write to test.txt from Windows
>> after
>> the chmod results in Access Denied. That DENY clause prevents
>> Windows
>> from doing that.
> Your problem appears to be that you are trying to fix your problem an
> hammer.
I don't follow. I am just trying to understand why it is behaving the
way it is.
>
>> # Global parameters
>> [global]
>> disable spoolss = Yes
>> guest account = guestuser
>> interfaces = lo 192.168.2.0/24
>> kerberos method = secrets and keytab
>> load printers = No
>> log file = /var/log/samba/%m.log
>> map to guest = Bad User
>> printcap name = /dev/null
>> realm = MYDOM.LOCAL.NET
>> security = ADS
>> server string = myserver
>> template homedir = /home/%U
>> template shell = /bin/bash
>> username map = /etc/samba/user.map
> What exactly is in the 'user.map' ?
!root = MYDOM\Administrator MYDOM\administrator
>
>> winbind enum groups = Yes
>> winbind enum users = Yes
>> winbind refresh tickets = Yes
>> winbind use default domain = Yes
>> workgroup = MYDOM
>> idmap config mydom : unix_primary_group = yes
>> idmap config mydom : range = 1000-29999
> I suppose you realise that using that range means you cannot have any
> local Unix users.
Correct. I could/should probably make it start at 1001 since I normally
create a 'local' user when initially setting up a system. But other than
the initial root user install/configuration, all users comes from the AD.
>> idmap config mydom : schema_mode = rfc2307
>> idmap config mydom : backend = ad
>> idmap config * : range = 30000-39999
>> idmap config * : backend = tdb
>> cups options = raw
>> hosts allow = 127. 192.168.2.
>> map acl inherit = Yes
>> printing = bsd
>> strict allocate = Yes
>> vfs objects = acl_xattr
>>
>> [TestShare]
>> comment = TestShare
>> create mask = 0770
>> directory mask = 0770
>> force create mode = 0770
>> force directory mode = 0770
>> force group = "TestShare Users"
>> path = /mnt/store/TestShare
>> read only = No
> I suggest you change the share to this:
>
> [TestShare]
> comment = TestShare
> path = /mnt/store/TestShare
> read only = No
>
> Then set the permissions from windows and only windows.
>
> Try reading:
> man mount.cifs
> https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs
>
> Rowland
>
>
>
I don't think that is going to work since I cannot control that the
Linux application is messing with permissions. When files are created
under Linux, the execute bit is typically not set.
So to support an application that can run on Windows and on Linux
against the same share I need a solution that will work.
Further testing...
On the server side, I removed
vfs objects = acl_xattr
map acl inherit = Yes
On the client side, I kept the cifsacl.
I found that if I 'chmod u-x test.txt', it removes BOTH wx user
attribute on the server making the file read-only on the server. That
does not seem right.
Next test, on the client side, I removed the cifsacl option, added
uid,gid to the mount.cifs and it works fine.
Looking at my old Centos 7 setup, it looks like I did not use the acl_xattr.