After archiving a directory tree with GNU tar and unpacking it on another Linux host, the named-user ACL entries are gone although the ordinary mode bits survived. Where does Linux store POSIX ACLs, and what decides whether they survive a copy or a restore?

## Two places permissions live A file's classic permissions are three fields in the on-disk inode: owner UID, group GID, and the mode word holding the nine `rwx` bits plus the special bits. Every tool that has ever copied a file understands them, and `stat` returns them without any filesystem-specific machinery. Extended ACL entries are not in the inode. They are stored as **extended attributes** — arbitrary name/value pairs attached to the file — under two reserved names in the `system` namespace: - `system.posix_acl_access` — the access ACL - `system.posix_acl_default` — the default (inheritance) ACL, on directories That single fact explains nearly every ACL-loss incident. Copying a file's permissions and copying a file's extended attributes are two different operations, and the second one is opt-in almost everywhere. ## Which tools carry them | Tool | Carries ACLs when | |---|---| | GNU `tar` | `--acls` is passed (`--xattrs` for other extended attributes) | | `rsync` | `-A` / `--acls` is passed — **not** implied by `-a` | | GNU `cp` | `-a` or `--preserve=all` | | `getfacl` / `setfacl` | always — that is their entire job | The `rsync` case is the classic production trap: `-a` is universally described as "archive mode, preserve everything", and it does preserve permissions, ownership, timestamps, symlinks and devices — but ACLs and extended attributes need `-A` and `-X` respectively, on both ends, with both builds supporting them. ## Which filesystems can hold them A filesystem must support extended attributes before it can hold an ACL: - `ext4`, `XFS` and `btrfs` support POSIX ACLs and enable them by default on current kernels. Older ext-family setups required an explicit `acl` mount option; that is now the default, and the `noacl` option exists to turn support off. - `tmpfs` supports them, which matters for containerised and `/run`-based layouts. - `vfat` and `exfat` have no extended attributes at all — an ACL simply cannot be represented, so a USB stick or an EFI partition is a one-way trip. - Network filesystems are their own topic: NFSv4 defines a richer ACL model that is not POSIX ACLs, so entries may be mapped, approximated or lost depending on server and client configuration. Never assume a POSIX ACL round-trips across a network filesystem without testing it. A restore that silently drops ACLs on a filesystem that cannot store them is not a bug in the tool; it is the destination refusing to represent the data. ## The tool-independent dump When you cannot guarantee the pipeline preserves extended attributes, take the ACLs out of band: ``` $ cd /srv/shared $ getfacl -R . > /var/backups/shared.acl ... move the data by whatever means ... $ cd /srv/shared $ setfacl --restore=/var/backups/shared.acl ``` `getfacl -R` walks the tree and prints a text record with `# file:` headers, and `setfacl --restore` replays it, including the `default:` entries. Because it is plain text it also makes a reviewable artefact — you can diff yesterday's ACL dump against today's and see what changed, which no `ls -l` will ever tell you. ## Why the mode still looks correct after the loss This is the part that makes the failure dangerous rather than merely annoying. On a file with an extended ACL, the group triad of the mode is the **mask**, not the owning group's own rights. When the extended entries are dropped in transit, the mask value stays behind in the mode word and is now interpreted literally as the owning group's permissions. So a file that was `-rw-rw----+` with a mask of `rw-` and an actual `group::r--` arrives as `-rw-rw----`, quietly granting the whole owning group write access it never had. The permissions did not just get *lost* — in the group triad they can get *widened*. That is why the verification step after any migration is `find` for the `+` marker or a re-run of `getfacl -R` compared against the source, rather than eyeballing `ls -l`. ## Practical checklist for a migration 1. Confirm the source tree actually uses ACLs (`getfacl -R` and look for named entries). 2. Confirm the destination filesystem supports them and is not mounted `noacl`. 3. Choose a transfer that carries them (`tar --acls`, `rsync -AX`, `cp -a`) *and* verify the tool on both hosts supports the option. 4. Take a `getfacl -R` dump before the move as your fallback and your audit record. 5. After the move, compare a fresh `getfacl -R` against the dump — not the modes.