[Help] SMB access denied for users on externally transferred files after TOS upgrade (tmacl_xattr bug)

[tasete30]

Hi everyone,

I discovered and fixed a TOS bug that prevents certain users from accessing SMB shares on files that were transferred to the NAS before/during an OS upgrade.

The problem
When files are copied into TOS from external sources (USB, FTP, torrents, etc.), TOS automatically generates a security.NTACL extended attribute containing ACL data.

I believe this bug was triggered during a major TOS upgrade (from v5 to v7 in my case). After upgrading:

Users that existed before the upgrade can access their files via SMB
Users created after the upgrade cannot access files, even though POSIX ACLs (getfacl) show they have full permissions
The TOS tmacl_xattr VFS module reads the pre-existing NTACL, doesn't find the new user, and denies SMB access — despite POSIX ACLs being correct. Direct filesystem access works fine. Only SMB is broken.

How to diagnose
Copiar
# Check if files have NTACL xattr
getfattr -n "security.NTACL" "/path/to/file"

# Verify POSIX ACLs are correct
getfacl "/path/to/file"
If NTACL exists but the user is not listed in the POSIX ACL output, this is likely the issue.

The fix
Remove the stale NTACL xattr so TOS falls back to POSIX ACLs:

Copy
# Remove NTACL from all files on affected volume
find /VolumeX -type f -exec setfattr -x security.NTACL {} \;

# Ensure proper permissions
chgrp -R allusers /VolumeX/
chmod -R o+rx /VolumeX/
After this, SMB access works normally. The tmacl_xattr module then correctly reads the POSIX ACLs.

Environment
TOS version: 7.0.1140 (Build 20260716)
Upgrade path: TOS v5 → TOS v7 (upgrade likely triggered the issue)
NAS model: TNAS8408
Samba: 4.15.13-Ubuntu
Affected: Only files with externally generated security.NTACL xattrs
Question for TerraMaster
Should the aclconv service (which runs at boot to sync ACLs) also regenerate NTACL when it detects a mismatch with POSIX ACLs? Currently it appears to preserve existing NTACL data even when it does not reflect the current user/permission configuration. This could affect many users who upgraded TOS and created new user accounts afterwards.

Hope this helps anyone experiencing the same issue.

[EriChan]

Thank you very much for sharing such a detailed technical analysis and workaround with the community!

Regarding your question on whether the aclconv service should reconcile or regenerate security.NTACL when detecting mismatches with POSIX ACLs (particularly across major upgrades and newly added users): we have forwarded your insights directly to our product team for evaluation.

To assist us in further investigation, could you please go to TOS Desktop > Support & Help > Issue Report, generate and download a system report, and send it to our technical support team?

Thank you again for your valuable contribution and support!