samba - Mar 2018 - Changing Windows permissions runs very slow

Is it normal for changing of Windows ACL permissions to run very slow? 
I've tried running perm changes across a lot of files (like 1TB) in user 
directories by interactive session from a domain-connected Windows 
desktop AND from the command line on the Samba server itself like this

find install -type f -exec samba-tool ntacl set 
"O:LAG:S-1-22-2-0D:AI(A;ID;0x001f01ff;;;S-1-5-21-1719490861-3494379899-4222726569-1105)(A;ID;0x001200a9;;;S-1-5-21-1719490861-3494379899-4222726569-1106)(A;ID;0x001200a9;;;DU)(A;ID;0x001f01ff;;;DA)"
{} \;

While I feel like the command-line version is running faster, but 
methods seem to take a very long time, like days.

When I monitor the Samba server utilization while doing the interactive 
method, a sole smbd process runs at about 90-100%, which I suppose is 
expected because it's running across a share and I guess smbd is not 
going to run on multiple cores.

When I monitor the Samba server while doing the local command-line 
version, no process seems to be running at high utilization and the 
drives are barely lighting up. This is all on a Dell dual-cpu xeon 
server with 32gb ram and a bunch of raid drives. I realize the 
samba-tool command is being repeatedly executed as the find recurses, 
but I would have expected a much more lively server while this was running.

Seems like the perm changes take a really long time and I'm curious if 
something is wrong on my end. The Samba server is the sole server in the 
domain and also running DC role. I realize this is not the ideal 
configuration for the file server role.

On Tue, 2018-03-13 at 00:27 -0400, Ken McDonald via samba
wrote:
> Is it normal for changing of Windows ACL permissions to run very slow? 
> I've tried running perm changes across a lot of files (like 1TB) in
user
> directories by interactive session from a domain-connected Windows 
> desktop AND from the command line on the Samba server itself like this
> 
> find install -type f -exec samba-tool ntacl set 
>
"O:LAG:S-1-22-2-0D:AI(A;ID;0x001f01ff;;;S-1-5-21-1719490861-3494379899-4222726569-1105)(A;ID;0x001200a9;;;S-1-5-21-1719490861-3494379899-4222726569-1106)(A;ID;0x001200a9;;;DU)(A;ID;0x001f01ff;;;DA)"
> {} \;
The implementation of samba-tool ntacl is known to be quite
inefficient.  There are a lot of repeated calls to winbind and even in
the 'sysvolreset' subcommand (which could share the internal connection
setup) this isn't implemented well. 
> While I feel like the command-line version is running faster, but 
> methods seem to take a very long time, like days.
> 
> When I monitor the Samba server utilization while doing the interactive 
> method, a sole smbd process runs at about 90-100%, which I suppose is 
> expected because it's running across a share and I guess smbd is not 
> going to run on multiple cores.
Interesting. 
> When I monitor the Samba server while doing the local command-line 
> version, no process seems to be running at high utilization and the 
> drives are barely lighting up. This is all on a Dell dual-cpu xeon 
> server with 32gb ram and a bunch of raid drives. I realize the 
> samba-tool command is being repeatedly executed as the find recurses, 
> but I would have expected a much more lively server while this was running.
> 
> Seems like the perm changes take a really long time and I'm curious if 
> something is wrong on my end. The Samba server is the sole server in the 
> domain and also running DC role. I realize this is not the ideal 
> configuration for the file server role.
Sadly no, this has been seen elsewhere.  We just haven't had time to
look into it (no pun intended). 

Andrew Bartlett


-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba