Windows AD Share Permission

[Ilie]

Hello Everyone,

I have one task which i cannot solve for 2 days already. The task is simple - to share (through SMB) one folder in FreeNAS where users (from AD) can create/add any files - but delete only their owned folder/files.
In Windows Advanced Security Settings - i set the rights in the following order:

CREATOR OWNER - FULL CONTROL
Domain Users - Read Only
Domain Users - Special (Create files/write data and Create folders/append data)

But, it is not working - any users can remove any files even if they are not owners.
What i observed - is that together with "Create Files" permission - automatically are checked and "Delete subfolders and files" permission as well, and uncheck it is not possible. He are checked automatically after pressing "OK" button.
Is there any other way to solve this issue? How can i uncheck this flag "Delete subfolders and files" by leaving Create files - checked. On others shares - these settings are working ok.

Thank You.

 

[anodos]

Hello Everyone,

I have one task which i cannot solve for 2 days already. The task is simple - to share (through SMB) one folder in FreeNAS where users (from AD) can create/add any files - but delete only their owned folder/files.
In Windows Advanced Security Settings - i set the rights in the following order:

CREATOR OWNER - FULL CONTROL
Domain Users - Read Only
Domain Users - Special (Create files/write data and Create folders/append data)

But, it is not working - any users can remove any files even if they are not owners.
What i observed - is that together with "Create Files" permission - automatically are checked and "Delete subfolders and files" permission as well, and uncheck it is not possible. He are checked automatically after pressing "OK" button.
Is there any other way to solve this issue? How can i uncheck this flag "Delete subfolders and files" by leaving Create files - checked. On others shares - these settings are working ok.

Thank You.

Post contents of /usr/local/etc/smb4.conf.

 

[Ilie]

[global]
server max protocol = SMB3
encrypt passwords = yes
dns proxy = no
strict locking = no
oplocks = yes
deadtime = 15
max log size = 51200
max open files = 463322
logging = file
load printers = no
printing = bsd
printcap name = /dev/null
disable spoolss = yes
getwd cache = yes
guest account = MYDOMAIN\guest
map to guest = Bad User
obey pam restrictions = yes
ntlm auth = no
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
dos filemode = yes
multicast dns register = yes
domain logons = no
idmap config *: backend = tdb
idmap config *: range = 90000001-100000000
server role = member server
workgroup = MYDOMAIN
realm = MYDOMAIN.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 MYDOMAIN: backend = rid
idmap config MYDOMAIN: range = 20000-90000000
allow trusted domains = no
client ldap sasl wrapping = plain
template shell = /bin/sh
template homedir = /home/%D/%U
netbios name = STORAGE
pid directory = /var/run/samba
create mask = 0666
directory mask = 0777
client ntlmv2 auth = yes
dos charset = CP1251
unix charset = UTF-8
log level = 1


[common]
path = "/mnt/data/files/common"
comment = Common Files
printable = no
veto files = /.snapshot/.windows/.mac/.zfs/
writeable = yes
browseable = yes
vfs objects = zfs_space zfsacl acl_xattr acl_tdb streams_xattr aio_pthread
hide dot files = yes
guest ok = no
nfs4:mode = special
nfs4:acedup = merge
nfs4:chown = true
zfsacl:acesort = dontcare

 

[anodos]

That's interesting. I'm seeing the same thing on my computer. The ZFS permission associated with this is "Delete Child" (d). The permission box appears checked even when the underlying permission is not granted on the filesystem. Is Windows lying to you or can users delete subfolders that they shouldn't have access to?

By the way, turn off acl_xattr and acl_tdb. You already have zfsacls enabled. Having three different methods of storing ACL information enabled simultaneously is bound to cause problems.

 

[anodos]

By the way (part 2), if you need to use "CREATOR-OWNER", you should set the auxiliary parameter on your share nfs4:mode = simple then restart Samba & start new session on server.

 

[Ilie]

That's interesting. I'm seeing the same thing on my computer. The ZFS permission associated with this is "Delete Child" (d). The permission box appears checked even when the underlying permission is not granted on the filesystem. Is Windows lying to you or can users delete subfolders that they shouldn't have access to?

I'm not sure that Windows is lying - users can delete any subfolders that are not owned by them.

By the way, turn off acl_xattr and acl_tdb. You already have zfsacls enabled. Having three different methods of storing ACL information enabled simultaneously is bound to cause problems.

OK, thank you for suggestion - i will do so.

 

[Ilie]

By the way (part 2), if you need to use "CREATOR-OWNER", you should set the auxiliary parameter on your share nfs4:mode = simple then restart Samba & start new session on server.

I tried and this settings - behavior is the same... :(

 

[Ilie]

Okay. I just independently confirmed this issue. Samba is very liberal with granting "delete child". You should file a bug on Samba's bugtracker: https://bugzilla.samba.org/

Ok, thank you for support ;)

 

[anodos]

Well, it appears the problem is related to how NFSv4 ACLs work in FreeBSD:

Code:

r = read file, view directory contents;
w = create/edit/append/delete files;
x = execute file, view directory contents;
p = create sub-directory;
d = allows deleting a file or directory, even if (you) don't possess ownership or write permission to it;
D = allows deletion of a child file or child directory (subdirectory), when D is set on its parent directory; regardless of whether subject possesses ownership or write permission to the directory (on which D is set), or a child object of it; can ONLY be set on a directory object;
a = read attributes (e.g. atime);
A = change attributes (e.g. update a time);
R = read xattribs;
W = change/add xattribs;
c = read ACL with getfacl;
C = change/add ACL with setfacl;
o = change owner of file (seems redundant, only root can change a file's owner);
s = sync (also seems redundant);

So it appears W implies "delete"
See discussion here: https://lists.freebsd.org/pipermail/svn-src-head/2016-June/088709.html

 

[anodos]

Okay. Found a solution per the above linked entry. You need to add an explicit "DENY" ACE for "Delete folders and subfolders".

Edit: the above didn't work as a solution because the DENY ACE takes precedence over the owner@:allow ACE.

 

[Ilie]

Okay. Found a solution per the above linked entry. You need to add an explicit "DENY" ACE for "Delete folders and subfolders".

@mav@ - is this correct? Currently, in FreeBSD "write data" implies "delete" and "delete child"? Will the behavior change?

I tried this way - and it's blocking files/folders for deleting, but in this case user cannot delete any files/folders even if he are own them.

 

[anodos]

I tried this way - and it's blocking files/folders for deleting, but in this case user cannot delete any files/folders even if he are own them.

Try the following:

• create new dataset with "Unix" permissions type.
• create new SMB share pointing to the dataset.
• add the below "auxiliary parameters" for the share:

Code:

vfs objects = zfs_space acl_xattr streams_xattr aio_pthread
acl_xattr:ignore system acls = yes

This will cause Samba to store ACLs as extended attributes. If there is a problem with how FreeBSD is interpreting "write data", "delete", and "delete child", then these parameters should work around it. Note that once you do this, you should only access the data on the share via Samba.

I filed a bug report on the FreeNAS bugtracker here: https://bugs.freenas.org/issues/24130

 

[Ilie]

Try the following:

• create new dataset with "Unix" permissions type.
• create new SMB share pointing to the dataset.
• add the below "auxiliary parameters" for the share:

Code:

vfs objects = zfs_space acl_xattr streams_xattr aio_pthread
acl_xattr:ignore system acls

This will cause Samba to store ACLs as extended attributes. If there is a problem with how FreeBSD is interpreting "write data", "delete", and "delete child", then these parameters should work around it. Note that once you do this, you should only access the data on the share via Samba.

I filed a bug report on the FreeNAS bugtracker here: https://bugs.freenas.org/issues/24130

Hi,

I did like you proposed - but in this way i cannot open this share - even for read. FreeNAS are integrated with active directory. See attached picture with permission for that volume.
Thank you.

 

[anodos]

Hi,

I did like you proposed - but in this way i cannot open this share - even for read. FreeNAS are integrated with active directory. See attached picture with permission for that volume.
Thank you.

PM me a debug file. System->Advanced->Save Debug. I might not be able to view it until Monday.

 

[LifeMan]

I have the same issue. Did Enybody solve the issue?

 

[anodos]

I have the same issue. Did Enybody solve the issue?

acl_xattr is currently broken in FreeBSD. I will look into this again later and file a bug ticket. With zfs acls "append" implies "delete". The only way to be able to append, but not delete is to set an explicit "deny delete" ACE for the group in question.

 

[hemi]

I am having this problem in 2020 did this bug ever get fixed?