How to recover permissions and ACLs lost after a backup restore on a Linux server without stopping services (step-by-step)

By · Published on · 9 min read

Laptop with red backlit keyboard and screen showing digital interface panels
Tech-looking visual suitable for technical guides on Linux permissions and ACLs. Photo: Rafael Minguet Delgado / Pexels

How do you recover permissions and ACLs lost after restoring a backup on a Linux server without taking services offline? Fix metadata (permissions, owners, ACLs and xattrs) safely while keeping processes running. Learn how to diagnose what changed, restore only attributes from a snapshot or trusted reference, and validate results before closing the incident.

What really gets lost when a backup ignores metadata

When a restore doesn't preserve metadata, you lose modes (chmod), owners and groups (chown), ACLs, extended attributes (xattrs) and, on SELinux systems, security contexts. Services may keep running, but reopening files or creating new writes can fail.

Common symptoms help you prioritize immediate fixes. Use them to limit the scope and reduce the risk of broad, unnecessary changes.

  • 403/401 on the web server after restoring a site even though content is intact.
  • Services unable to create files in spool/cache directories due to missing permissions.
  • Database can't access its data directory because of wrong owner.
  • systemd scripts won't run because the executable bit was lost.
  • Fine-grained ACLs for shared folders disappeared, breaking team access.
Component (example) Directory Typical owner Typical permission Note
PostgreSQL /var/lib/postgresql/... postgres:postgres 700 Prefer PITR for data; here we deal with metadata.
Nginx /var/www/site www-data:www-data dirs 750, files 640 May involve ACLs for CI/CD.
Queue/Cache (Redis) /var/lib/redis redis:redis 770 Check systemd tmpfiles.d.
Jobs (app) /srv/app deploy:www-data dirs 755, files 644 Varies by stack and internal policy.

How to diagnose which permissions and ACLs were lost

Diagnosis compares the current state with a trusted reference. A mounted LVM snapshot, a previous backup that preserved metadata, or a sibling server are good references. Without a reference, collect risk signals and prioritize critical areas.

Check whether the filesystem supports ACLs and that it isn't mounted with noacl. Generate inventories of permissions and ACLs to compare and version. If you don't have automated snapshots yet, see the guide on LVM snapshots with Restic to S3.

# 1) Verifique opções de montagem (procure 'acl' ou 'noacl')
findmnt -no SOURCE,FSTYPE,OPTIONS /

# 2) Liste donos/permissões rapidamente (ex.: webroot)
find /var/www -xdev -printf '%m %u:%g %p\n' | head -n 20

# 3) Inspecione ACLs atuais (prefixos absolutos com -p)
getfacl -R -p /var/www | head -n 40

# 4) Se tiver um snapshot montado em /mnt/snap, gere dumps p/ diff
getfacl -R -p /mnt/snap/var/www > /root/acl.ref
getfacl -R -p /var/www         > /root/acl.now

diff -u /root/acl.ref /root/acl.now | sed -n '1,200p'

How to recover metadata from a snapshot without stopping services

Restoring only metadata is possible and safe for running services because chmod/chown/setfacl are atomic inode operations. Run as root and test in a staging directory first.

The strategy: mount the backup read-only, apply attributes without copying content, and reapply ACLs/xattrs. Back up current metadata for a quick rollback. For synchronizations remember rsync with -A -X; for migrations with minimal downtime, see the step-by-step to migrate Docker host with rsync.

  • Mount the snapshot/backup read-only (ro).
  • Save current metadata (ACLs/xattrs) for rollback.
  • Apply attributes with cp --attributes-only.
  • Restore ACLs with setfacl --restore and xattrs with setfattr --restore.
  • Work surgically: one path at a time (e.g. /srv/app, /var/www).
# Exemplo: restaurar metadados de /srv/app a partir de /mnt/snap/srv/app
# 0) Backups de metadados atuais (rollback)
getfacl  -R -p /srv/app > /root/acl.before
getfattr --dump -R /srv/app > /root/xattr.before || true

# 1) Aplique donos/permissões/tempos SEM tocar no conteúdo
cp -a --attributes-only /mnt/snap/srv/app/. /srv/app/

# 2) Restaure ACLs a partir do snapshot
getfacl -R -p /mnt/snap/srv/app | setfacl --restore=-

# 3) Restaure atributos estendidos (xattrs)
getfattr --dump -R /mnt/snap/srv/app > /root/xattr.dump || true
setfattr --restore=/root/xattr.dump  || true

Safely restoring ACLs and extended attributes

ACLs provide fine-grained permissions beyond the owner/group/other trio. Xattrs include markings such as capabilities and, on some distributions, MAC labels. Errors can block access; always validate on smaller directories first.

If SELinux is enabled, relabel contexts after restoring xattrs/ACLs. With AppArmor, review profiles if directories moved.

  • Use getfacl -R -p on the snapshot and setfacl --restore on the target.
  • For xattrs, combine getfattr --dump and setfattr --restore.
  • On SELinux, run restorecon -RF on the affected scope.
  • Avoid applying changes recursively on /; operate by component.
# ACLs e xattrs de um diretório compartilhado
getfacl -R -p /mnt/snap/data/shared | setfacl --restore=-
getfattr --dump -R /mnt/snap/data/shared > /root/shared.xattrs || true
setfattr --restore=/root/shared.xattrs || true

# SELinux (se aplicável)
command -v getenforce >/dev/null 2>&1 && restorecon -RF /data/shared || true

What if I don't have a snapshot with correct metadata?

Without a reference, reconstructing metadata requires rules. For binaries and package-managed files, restore defaults from the package database. For application data, adopt conservative defaults and review exceptions with peers.

On RPM-based systems, package metadata can be restored from the local database. On Debian/Ubuntu, check dpkg-statoverride and consider controlled reinstalls during a maintenance window.

  • RPM (RHEL/CentOS/Fedora): use rpm --setperms -a and rpm --setugids -a.
  • Debian/Ubuntu: consult dpkg-statoverride --list for directories with overrides.
  • For apps: adopt safe defaults (dirs 750/755, files 640/644) and adjust exceptions.
  • Review capabilities (getcap/setcap) if your stack uses file capabilities.
# RPM-based: restaurar donos e permissões padrão de pacotes
rpm --setperms -a
rpm --setugids -a

# Debian/Ubuntu: listar overrides registrados
dpkg-statoverride --list | sed -n '1,50p'

# Capabilities (se usados)
getcap -r /usr/bin 2>/dev/null | sed -n '1,50p'

How to prevent this from happening on the next backup

Prevent recurring losses by ensuring your backup preserves metadata. Tools should capture ACLs and xattrs and restore them by default. Also include ACL/xattr dumps alongside backups for auditability.

Test restores periodically in a staging environment. Use snapshots to reduce inconsistency windows and minimize active service copies. For a robust deployment, see our guide on encrypted incremental S3 backups.

  • Rsync: use -aAX (archive + ACLs + xattrs) and validate with --dry-run.
  • Tar/bsdtar: include --acls and --xattrs when creating/extracting.
  • Attach dumps: getfacl --absolute-names and getfattr --dump in the same job.
  • Document scope: exclude /proc, /sys, /dev, /run and ephemeral mounts.
  • Schedule restore tests with systemd timers and LVM snapshots.
# Exemplo de sincronização que preserva metadados (somente leitura no destino antes)
rsync -aAX --numeric-ids --info=SKIP,NAME --dry-run /origem/ /destino/

# Dumps anexos no job de backup
getfacl  -R --absolute-names /srv/app > /backup/refs/acl.srv-app
getfattr --dump -R              /srv/app > /backup/refs/xattr.srv-app

Final checks and post-fix audit

Validate that services can create and read files. Look for dangerous bits and inconsistencies. Produce a final report comparing ACLs before/after and archive it in a safe location.

If systemd unit files or configs were affected, a daemon-reload is usually enough; restarting services is not required if the content didn't change. For containerized environments, see bind-mount practices in the guide to move large Docker volumes to another disk.

  • Write/read tests in the app (for example: temporary upload).
  • Check for unexpected world-writable files and SUID bits.
  • Compare ACLs before/after to close the incident.
  • Consider reloading services that read configs on demand.
# World-writable e SUID/SGID suspeitos no escopo tratado
find /srv/app -xdev \( -perm -0002 -o -perm -2000 -o -perm -4000 \) -ls

# Diff de ACLs
getfacl -R -p /srv/app > /root/acl.after
diff -u /root/acl.before /root/acl.after | sed -n '1,200p'

# Reload (se necessário)
systemctl daemon-reload || true
# Ex.: nginx, php-fpm, etc. (apenas reload se alterou configs)
# systemctl reload nginx || true

Related resources and when to use PITR

When the loss affects only a database, consider restoring at the database level (PITR) instead of manipulating files in the data directory. For filesystem backups, snapshots reduce risk and preserve metadata.

See practical materials to implement snapshots and verifiable backup routines on Linux servers. For PostgreSQL databases, the guide on recovering a dropped table with PITR without downtime dives deeper into the strategy.

Frequently asked questions

Do I need to stop services to restore permissions and ACLs?

In most cases, no. chmod, chown and setfacl are atomic operations and don't require a restart. If you didn't change file content, a service reload may be enough when configs are read dynamically.

Can I recover ACLs from a backup made with tar or standard rsync?

Yes, if the backup stored ACLs and xattrs. With tar, use the --acls and --xattrs options. With rsync, preserve -A and -X. If metadata wasn't saved, use a reference (snapshot or sibling host) to reconstruct ACLs.

What if the filesystem is mounted with noacl?

Re-enable ACL support by remounting with the acl option or enabling it in /etc/fstab. Without ACL support, setfacl has no effect and fine-grained permissions are unavailable.

How do I treat Docker volumes or bind mounts during correction?

Adjust owners/permissions/ACLs on the host paths of the volumes. Map the UIDs/GIDs used by containers and apply chown/chmod/setfacl on the real volume path, avoiding changes to image layers.

Will reinstalling packages fix system permissions?

On RPM distributions, rpm --setperms/--setugids restores package defaults. On Debian/Ubuntu, reinstalling may restore defaults but can overwrite configs. Plan changes in a maintenance window and back up beforehand.

Need help now?

If a restore has scrambled permissions and ACLs, we can build a safe plan and apply fixes without taking services down.

Talk about your case

See also