Handle prune permission errors from preserved snapshot directory modes #65

New Issue

parkel · 2026-05-27T01:33:38+02:00

parkel commented

2026-05-27 01:33:38 +02:00

Problem

A backup run can complete successfully while the follow-up prune step fails with a PermissionError when deleting an older snapshot. Example:

[Errno 13] Permission denied: '/mnt/backups/pobsync/<host>/scheduled/<snapshot>/data/var/lib/snapd/void'

The new snapshot is valid (rsync exit_code=0, run status success), but pobsync reports a warning because pruning could not remove an older snapshot. This can happen because rsync --archive preserves restrictive directory modes from the source, and the pobsync service user may not be able to traverse/delete those directories later.

Expected

Prune should handle preserved restrictive permissions more robustly, without turning a successful backup into confusing operator noise.

Ideas

During snapshot deletion, make directories inside the snapshot tree traversable/writable before removing them.
Keep path safety checks so prune cannot chmod/delete outside the intended snapshot root.
Record actionable prune diagnostics in the run result when permission repair is needed or fails.
Add tests for deleting snapshots containing read-only or non-traversable directories.
Document excludes such as /var/lib/snapd/*** as a workaround when those trees are not useful for restore.

Acceptance criteria

Retention/prune can delete snapshots that contain restrictive directory modes copied from the source.
Permission handling is limited to the snapshot directory being deleted.
Failed prune still reports a clear warning with an actionable path and reason.

## Problem A backup run can complete successfully while the follow-up prune step fails with a `PermissionError` when deleting an older snapshot. Example: ```text [Errno 13] Permission denied: '/mnt/backups/pobsync/<host>/scheduled/<snapshot>/data/var/lib/snapd/void' ``` The new snapshot is valid (`rsync exit_code=0`, run status success), but pobsync reports a warning because pruning could not remove an older snapshot. This can happen because rsync `--archive` preserves restrictive directory modes from the source, and the pobsync service user may not be able to traverse/delete those directories later. ## Expected Prune should handle preserved restrictive permissions more robustly, without turning a successful backup into confusing operator noise. ## Ideas - During snapshot deletion, make directories inside the snapshot tree traversable/writable before removing them. - Keep path safety checks so prune cannot chmod/delete outside the intended snapshot root. - Record actionable prune diagnostics in the run result when permission repair is needed or fails. - Add tests for deleting snapshots containing read-only or non-traversable directories. - Document excludes such as `/var/lib/snapd/***` as a workaround when those trees are not useful for restore. ## Acceptance criteria - Retention/prune can delete snapshots that contain restrictive directory modes copied from the source. - Permission handling is limited to the snapshot directory being deleted. - Failed prune still reports a clear warning with an actionable path and reason.

parkel added this to the 1.2 milestone 2026-05-27 01:33:38 +02:00

parkel referenced a pull request that will close this issue

2026-05-28 20:59:20 +02:00

(bugfix) Make snapshot pruning robust to archived permissions #66

parkel closed this issue

2026-05-28 20:59:24 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: hippogrief/pobsync#65