Permissions mangling needs some serious Frank Sinatra style loving

[gcooper]

The way things are done in the permissions setting stuff can be improved with a minimal number of lines of code to be faster/smarter. I've gotten a ton of complaints from users/customers about this being slow, and the reason why is that it's horribly serialized (even though filesystems in general aren't) and uses a brute force method for applying permissions.

My thoughts on how things should be done:

1. If I don't change permissions, it shouldn't do anything.
2. If I change the mode, it should change everything.
3. If I change the owner/group, it should run chown.
4. If I change the ACLs type, it should set the ACLs via setfacl.

[*] A force button should be added, just in case someone _wants_ to do an operation.

Furthermore, some profiling needs to be done to determine where the exact root issue lays, because even though the current code is serialized, it typically eats up a single core doing filesystem operations via python (!). My hunch is that it's because setfacl is being called by subprocess _a lot_ and there's a lot of jumping up and down class methods (e.g. busy work) instead of everything being written out to a file and then batched through setfacl -M . That's just a WAG though.

[jhixson]

When this "feature" was implemented, the idea was that system administrators would create a share, set it to the appropriate type, then continue administrating it that way. For example, a windows system administrator would create a CIFS share, set the share up to use windows ACL's, then do all administration from windows. It was never designed to take preexisting data and reset it. So, it works as it was designed. I have, however, added a new utility to FreeNAS that can reset windows ACL's in a quicker/faster manner and that is why I am closing this ticket out. Please us /usr/local/www/freenasUI/tools/winacl.sh for this purpose.