Can't modify/delete after upgrading to 12.0 U3

[archialsta]

Hello everyone!

Previously I had installed TrueNAS 12.0 U2.1, and everything worked fine. Then, I updated to 12.0 U3 and one issue in particular came across.
With every type of user, when I want to copy or make a new file there is no problem, but when I decide to delete or modify it, says that I don't have the authorization of 'studio' for example to do it, that is the same user that I'm logged in and also created that file 5 seconds ago..

I did a 'getfacl /mnt/Data-22TB-Z', these are the results:

This are the ACL settings:


When it say I can't delete the file because I don't have the authorization (of myself):

Only when I modify manually the security settings (full control) of the file I can delete or modify it:

 

[anodos]

Can you PM me a debug please?

 

[anodos]

Ah, tracked it down:

Code:

commit c1a37b4f31d5252ce074d41f69e526aa84b0d3b3
Author: Andrew Walker <awalker@ixsystems.com>
Date:   Thu Sep 24 16:04:12 2020 -0400

    vfs_zfsacl: only grant DELETE_CHILD if ACL tag is special
    
    When ZFS aclmode is set to "passthrough" chmod(2)/fchmod(2) will result
    in special entries being modified in a way such that delete, delete_child,
    write_named_attr, write_attribute are stripped from the returned ACL entry,
    and the kernel / ZFS treats this as having rights equivalent to the desired
    POSIX mode. Historically, samba has added delete_child to the NFSv4 ACL, but
    this is only really called for in the case of special entries in this
    particular circumstance.
    
    Alter circumstances in which delete_child is granted so that it only
    is added to special entries. This preserves the intend post-chmod behavior,
    but avoids unnecessarily increasing permissions in cases where it's not
    intended. Further modification of this behavior may be required so that
    we grant a general read or general write permissions set in case of
    POSIX read / POSIX write on special entries.
    
    BUG: https://bugzilla.samba.org/show_bug.cgi?id=14471
    
    Signed-off-by: Andrew Walker <awalker@ixsystems.com>
    Reviewed-by: Ralph Boehme <slow@samba.org>
    Reviewed-by: Jeremy Allison <jra@samba.org>

There was an old and bad behavior in vfs_zfsacl. Got fixed upstream. Problematic filesystem ACL in this user's case was for an explicit group entry and lacked DELETE | DELETE_CHILD. After upstream version bump, Windows SD generated by Samba no longer granted these delete rights that weren't present in the ZFS ACL. As a result, request to open file with DELETE access failed with STATUS_ACCESS_DENIED. Solution is to grant the group delete rights.