I want to allow the root user of my Ubuntu OS 'FULL-CONTROL' of all my NTFS (msftdata) partitions so I can create my desired permissions separately for the Linux accounts
You don't really need to do this – root on Linux always has the privilege of ignoring all local file permissions and this applies to NTFS as well. This means that root doesn't need to be listed in the ACL in order to modify it with
setfacl: it can just always do that.
(Permissions and ACLs are not enforced by the filesystem itself – they are only enforced by the OS that's accessing it. The filesystem is just a data structure and cannot actively prevent the OS from outright ignoring it whenever convenient. Windows will ignore them when the caller has SeBackupPrivilege, Linux will ignore them when the caller has CAP_DAC_OVERRIDE, and so on.
For example, by default, the Linux NTFS-3G filesystem driver just doesn't enforce the NTFS ACLs entirely and gives the same access to all Linux UIDs, with synthetic file modes based purely on mount options. If you're seeing NTFS ACLs being enforced on Linux, that's something you enabled!)
setfacl is definitely inconvenient to use as it's meant to control POSIX ACLs and not NT ACLs, so what you probably should do is tell NTFS-3G how to map each Linux UID to a Windows SID:
Create a directory named
.NTFS-3G at the root of your NTFS volume.
In that directory, create a text file named
UserMapping (no file extension) with contents similar to:
With a mapping file, the Linux NTFS-3G driver will be able to treat your Linux account as the same entity as your Windows account, as far as file permissions are concerned. (Account names don't need to match.)
If you want to give access to accounts that only exist on Linux, you can still use chown/chmod/setfacl as root – or you can create dummy accounts on Windows, add mappings for their SIDs in the file, and be able to grant access through the Windows ACL editor.
The same way that NT-AUTHORITY/SYSTEM always has full control over drives even if the Windows users listed in the NTFS permissions do not exist on the Windows machine,
Only as long as SYSTEM itself is present in their ACLs. If you remove SYSTEM from a file's ACL, userspace processes running under this account lose access to that file just like any other account would.
the data is recoverable by leveraging the permissions of the NT-AUTHORTY/SYSTEM account because of it's universal SID (Security Identifier) across Windows machines.
Well, that's one possible method, but elevating a process to SYSTEM isn't something that's directly supported by Microsoft and ends up needing various "magic" tools. Besides, you can't actually rely on it – if someone has removed Administrators from an ACL, they can remove SYSTEM from the ACL all the same.
Instead, most "recovery" operations in Windows are based on Administrators having the OS-level privilege to change file ownership regardless of ACLs (SeTakeOwnershipPrivilege), together with the standard ACL logic which allows file owners to set new ACLs regardless of existing ACLs. The file manager will even offer to do this for you.
Alternative methods include activating SeBackupPrivilege, another OS-level privilege which completely bypasses permission checks for read operations; there is one for write operations as well. By default, all Administrators have this privilege available on demand (though unlike root on Linux, it is not active the whole time).