About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
Checking whether files are back is only one part of a Linux restore. A restored file can pass that test and still be wrong. An extra user's access may be gone, a security label missing, or a program's special capability stripped so it no longer starts.
Those details are not in the file's contents, nor in the familiar owner, group and mode bits. They live in access control lists (ACLs) and extended attributes. The three tools most people reach for, tar, rsync and cp, treat them differently, and none of them carries all of them by default.
This guide sets out what each tool's own documentation says, and how to confirm a copy kept what it should.
Why it matters
ACLs are common on shared folders, where several groups need different access. Extended attributes are used by the system itself: the xattr(7) manual page gives system.posix_acl_access and security.selinux as examples of attribute names. The security namespace is also used "to implement file capabilities".
Our reading: if a backup drops these silently, the restore looks complete. The problem appears later, as permission denied errors for one team, a service refusing to start under SELinux, or a program that loses a capability it was granted.
How it works
What ACLs and extended attributes are
The acl(5) manual page describes POSIX ACLs as a way "to define more fine-grained discretionary access rights for files and directories." Every object has an access ACL. A directory can also have a default ACL that "governs the initial access ACL for objects created within that directory".
ACLs and the ordinary mode bits are linked: "The permissions defined by ACLs are a superset of the permissions specified by the file permission bits." When an ACL has a mask entry, "the group permissions correspond to the permissions of the ACL_MASK entry." Our reading: a tool that copies only the mode bits can therefore produce a file whose group permissions look right but whose named-user and named-group entries are gone.
Extended attributes are name and value pairs in four classes: "the security, system, trusted, and user extended attribute classes". Each has different access rules:
- security: used "by kernel security modules, such as Security Enhanced Linux, and also to implement file capabilities".
- system: "used by the kernel to store system objects such as Access Control Lists."
- trusted: "visible and accessible only to processes that have the CAP_SYS_ADMIN capability."
- user: for "arbitrary additional information such as the mime type, character set or encoding of a file."
Our reading: on Linux, POSIX ACLs are themselves stored as system extended attributes. That is why some tools handle them together and why the namespace rules below matter.
Seeing what is there
A file with an ACL is easy to miss in a normal listing. acl(5) says that for such a file ls -l shows the mode with a "+" after it. Our reading: anyone checking a restore by eye can see that an ACL exists, but not what it contains.
getfacl shows the contents. Its manual page notes two behaviours that matter when its output is used as a record. By default it removes the leading slash from absolute paths: --absolute-names keeps it, and without it the listing is written relative to wherever it is later applied. -n lists "numeric user and group IDs" in place of names. Our recommendation: keep both forms for important folders, because a name listing depends on the target system knowing the same users, while a numeric listing depends on the same ID numbers.
acl(5) also records how two everyday commands behave: "If the -p flag is specified, the cp(1) utility also preserves ACLs", and "The mv(1) utility always preserves ACLs". For both, the page adds: "If this is not possible, a warning is produced." Our reading: a warning is easy to lose in a long job's output, and these are statements about a single copy or move. They do not make either command a backup tool.
Limits on the destination
The destination file system must be able to hold what is being restored. xattr(7) notes: "The VFS-imposed limits on attribute names and values are 255 bytes and 64 kB, respectively." The manual describes additional filesystem-specific limits, but its single-block description must not be treated as universal for modern ext4. The kernel ext4 documentation describes external attribute-value inodes when the EA_INODE feature is enabled. Kernel version, enabled filesystem features and the attribute namespace all matter.
A restore onto a different filesystem can therefore fail or lose attributes even when the copy options are correct. Check the actual target feature set and representative large attributes; filesystem names alone do not establish compatibility.
rsync: archive mode leaves them out
The rsync manual describes --archive (-a) as "a quick way of saying you want recursion and want to preserve almost everything." It then warns: "Be aware that it does not include preserving ACLs (-A), xattrs (-X), atimes (-U), crtimes (-N), nor the finding and preserving of hardlinks (-H)."
With --acls, rsync will "update the destination ACLs to be the same as the source ACLs", but "The source and destination systems must have compatible ACL entries for this option to work properly."
With --xattrs, the namespaces copied depend on who runs it: "a copy being done by a super-user copies all namespaces except system.. A normal user only copies the user. namespace."
There is also a mode for backing up without super-user rights. --fake-super stores "the privileged attributes via special extended attributes that are attached to each file". These include ownership and permission bits the receiving user cannot set. The manual says it also handles ACLs and non-user attributes when those options are given, and calls it "a good way to backup data without using a super-user, and to store ACLs from incompatible systems."
Our reading: a backup made with --fake-super stores the real ownership and ACLs in special attributes on the backup copy, not on the files themselves. Restoring it requires decoding the saved attributes on the backup side and applying real ownership, permissions and ACLs at the destination with suitable privileges. The manual explicitly says fake-super affects only the side where it is enabled. Enabling it on the destination can leave the metadata encoded again rather than restore live permissions. A plain file copy does not decode those saved attributes. Record which mode was used.
GNU tar: stored only when asked, restored selectively
The GNU tar manual says that extended attribute support is off unless requested: --no-xattrs is "the default". The same applies to ACLs (--no-acls "is the default") and SELinux contexts have their own option.
When --xattrs or --acls is used while creating an archive, it "implies POSIX.1-2001 archive format (--format=pax)".
The important detail is on extraction. The manual says that with --xattrs, "all names are stored in the archive (with --create), but only 'user' namespace is extracted (if using --extract )." It explains why: "extracting those (often security related) attributes on a different system than originally archived can lead to extraction failures, or even misinterpretations." Other namespaces can be extracted with an explicit include pattern, after checking "the attributes are binary compatible with the target system".
Our reading: an archive can contain everything and still restore only part of it by default. Whoever restores needs to know which options the archive was created with and which namespaces should come back.
The formats page adds a compatibility note. Some tar implementations "cannot handle it properly" (the pax format) and will "extract any additional information (such as long file names) as extra plain text files". The manual also says ustar-capable readers should read most pax archives. For recovery, confirm support for the particular extended headers and metadata you need, rather than assuming that reading file contents proves complete compatibility.
cp: some kept, some quietly
The GNU Coreutils manual describes cp --archive as trying to "preserve SELinux security context and extended attributes (xattr), but ignore any failure to do that and print no corresponding diagnostic."
Our reading: cp -a can succeed without saying that some attributes were not copied. The explicit --preserve=xattr option behaves differently: "Preserve extended attributes of the file, or fail with full diagnostics." The mode attribute covers permissions "and (if possible) access control lists (ACLs)". The manual adds that "ACLs are not necessarily translated when the source and destination are on file systems with different ACL formats (e.g., NFSv4 versus POSIX formats)."
For a restore where every attribute matters, name the required attributes explicitly and inspect diagnostics, then compare the result. There is a further limit: the Coreutils source says an xattr preservation request is ignored if cp was built without xattr support. Exit status alone cannot establish that the build and destination preserved the intended metadata.
Saving ACLs separately
Compare effective permissions as well as the visible named entries. The ACL mask limits named-user and group-class permissions, so a restored entry can exist yet grant less access than expected. Directory default ACLs also affect files created after recovery, which a check of existing files will not reveal. A useful validation set includes a directory with inherited access, a file with a named-user entry, a security label and a file capability where those features are actually used. Verify both an allowed access and an intended denial using designated test accounts.
The ACL tools offer another approach. getfacl(1) prints each file's owner, group and ACL entries in a text form. setfacl(1) has a --restore option to "Restore a permission backup created by `getfacl -R' or similar". It "attempts to restore the owner and owning group" if the input has owner comments.
The manual page notes one detail that matters: if the input has no "flags comments (which define the setuid, setgid, and sticky bits)", setfacl clears them.
Our reading: a getfacl listing is a useful second record. It is human-readable, can be compared before and after, and survives a backup tool that drops ACLs. It depends on user and group names resolving the same way on the restore target.
A summary of defaults
From the manuals cited, in our words:
| Tool | ACLs by default | Extended attributes by default | Option to include | Restore caveat |
|---|---|---|---|---|
rsync -a |
Not preserved | Not preserved | -A, -X |
For -X, non-root normally copies user.*, and root skips system.*; ACLs travel with -A; --fake-super must decode on the source side; destination needs real privileges |
| GNU tar | Not stored | Not stored | --acls, --xattrs, --selinux |
By default only user.* extracted |
cp -a |
Preserved if possible | Tried; failures not reported | --preserve=xattr, --preserve=mode |
Different ACL formats not translated |
What to choose and why
These are our recommendations, drawn from the manuals above.
- Find out what you have. Before choosing options, check whether the data uses ACLs, SELinux labels, file capabilities or user attributes.
- Name the options explicitly in every backup job: ACLs, extended attributes and SELinux contexts where used. Do not rely on archive modes.
- Write down how the backup was made, including tool, version, options and any fake-super mode, and keep that record with the backup.
- Restore to a matching file system type where possible, or confirm the destination can hold large attributes.
- Keep a getfacl listing of important folders as an independent record.
- Prefer failure to silence: use options that report attributes they cannot copy.
- Verify after a test restore by comparing ACL listings and attribute dumps of a sample folder against the source.
- Relabel when the target differs. Where SELinux policy differs on the target, plan to relabel as the distribution documents, not copy labels blindly.
Risks and limits
- Archive modes are not complete copies: rsync's leaves out ACLs and attributes, tar's are off by default.
- Namespaces differ by user: non-root and default extraction limit what comes back.
- File systems impose size limits, so a restore to a different type can fail.
- Names must resolve the same way on the target for name-based ACL entries.
- NFSv4 ACLs are a separate subject and not translated by these tools.
- Nothing here was run. Behaviour is quoted from the documentation for planning; test on non-production data.
Sources
- acl(5), Linux manual page: https://man7.org/linux/man-pages/man5/acl.5.html
- xattr(7), Linux manual page: https://man7.org/linux/man-pages/man7/xattr.7.html
- getfacl(1), Linux manual page: https://man7.org/linux/man-pages/man1/getfacl.1.html
- setfacl(1), Linux manual page: https://man7.org/linux/man-pages/man1/setfacl.1.html
- rsync(1) manual: https://download.samba.org/pub/rsync/rsync.1.html
- GNU tar upstream manual source, Extended File Attributes and Formats: https://git.savannah.gnu.org/cgit/tar.git/plain/doc/tar.texi
- GNU Coreutils upstream manual source, cp invocation: https://raw.githubusercontent.com/coreutils/coreutils/master/doc/coreutils.texi
This article was originally published on .