Issue: Child datasets, either existing or newly created, are NOT inheriting the ACLs of the parent. This happens despite checking both “Apply permissions recursively” AND “Apply permissions to child datasets”.
“Apply permissions to child datasets” does not appear as an option UNTIL “Apply permissions recursively” is checked. After I check “Apply permissions to child datasets” I am prompted (with a “Warning…” message) to Confirm my selection. However, I am NOT prompted (with a “Warning…” message) to Confirm my selection after I check “Apply permissions recursively”.
After I click the “Save Access Control List” button, a popup briefly displays a progress bar, implying something is happening (as in ACLs being applied to child datasets). But no ACLs are changed to any child dataset beneath the parent I just configured; and I must modify each child ACLs manually.
midclt output exceeds the char size limit of posts. Let’s forklift this this exchange to email; I can send the output as a file attachment. We can resume the discussion here when you have parsed the output.
After I create(d) a hierarchy of datasets (in prep for an App installation), I notice(d) within the Details summary that the ACLs (for “owners@” and “group@”) of the child datasets did not inherit from the parent. I’m able to manually set them, of course.
That’s how ACLs work on all OSes (MacOS, Windows, Linux, FreeBSD, etc). The file’s owner is not a part of the ACL information when you’re dealing with owner entries. It’s either a special SID in windows S-1-3-0 or a special tag in other OSes. There’s just an entry in the ACL that basically means “File owner (whoever that is)” – full control.
FWIW, there are checkboxes in the UI for recursive operations to apply the owner / group, but this is usually not what an admin wants to do because you’ll basically lose information on who created files across the dataset.
