Remove acltype normalization for datasets
Description
Steps to Reproduce
Expected Result
Actual Result
Environment
Hardware Health
Error Message (if applicable)
Activity
Bug Clerk September 3, 2024 at 3:57 PM
This issue has now been closed. Comments made after this point may not be viewed by the TrueNAS Teams. Please open a new issue if you have found a problem or need to re-engage with the TrueNAS Engineering Teams.
Bug Clerk September 3, 2024 at 3:57 PM
This issue has now been closed. Comments made after this point may not be viewed by the TrueNAS Teams. Please open a new issue if you have found a problem or need to re-engage with the TrueNAS Engineering Teams.
Bug Clerk September 3, 2024 at 3:56 PM
24.04.2.1 PR: https://github.com/truenas/middleware/pull/14406
Bug Clerk August 30, 2024 at 5:37 PM
This issue has now been closed. Comments made after this point may not be viewed by the TrueNAS Teams. Please open a new issue if you have found a problem or need to re-engage with the TrueNAS Engineering Teams.
Bug Clerk August 30, 2024 at 5:33 PM
24.10-RC.1 PR: https://github.com/truenas/middleware/pull/14386
25.04 PR: https://github.com/truenas/middleware/pull/14377
When we were doing initial development of TrueNAS SCALE (pre-angelfish) a bug was encountered when importing pools from FreeBSD in which the acltype could be set to OFF. Eventually this bug was fixed on the ZFS side, but it was still early days of testing NFSv4 acltype on SCALE and so we didn't want early-adopter migrators to have broken shares. Thus we normalized creation of new datasets to be POSIX acltype if user had selected to inherit from top-level dataset.
After a few releases and user bug reports we realized we needed to have specific ZFS dataset properties set depending on acltype. For example that the aclmode should be DISCARD (discard internal ZFS acl) because changing acltype does not remove the internal ZFS ACL and it could still be evaluated in zfs_zaccess calls. This eventually necessitated raising ValidationErrors on dataset creation for invalid parameter combinations. Unfortunately, the normalization behavior introduced in angelfish testing was overlooked at this point, which could cause a situation in which pools from FreeBSD and Illumos/Solaris (where acltype now imported correctly as nfsv4acl on top-level datasets) would get flagged as needing normalization. This led to an invalid combination of acltype POSIX and aclmode PASSTHROUGH being set on new datasets when they were created to inherit from the top-level dataset.
Rather than fixing the normalization, at this point we're pretty confident about NFSv4 ACL type behavior in SCALE and can just remove the normalization logic entirely.