I wanted to share my experience following the suggestions in this thread regarding backing up an NS8 File Server using BackupPC.
Following @stephdl@davidep’s suggestion to run rsync within the Samba module context to preserve UID/GID mappings and ACLs, I implemented a wrapper script solution that successfully solved the backup issue.
Here are the exact steps I followed:
Created a wrapper script on NS8 (/usr/local/bin/rsync-samba-ns8.sh):
Set RsyncClientPath to /usr/local/bin/rsync-samba-ns8.sh
Backup Result: Full and incremental backups now complete successfully without errors, properly fetching data from /home/samba1/.local/share/containers/storage/volumes/.
Issue with Restore: While backups work reliably, I am encountering issues during restores.
The behavior is inconsistent when restoring directories (e.g., shares or homes):
Some restore attempts succeed completely.
Other attempts (or items within the same restore batch) fail abruptly midway.
Here are the log errors I am receiving in BackupPC:
2026-xx-xx xx:xx:xx restore started below directory /home/samba1/.local/share/containers/storage/volumes/shares to host xxx.xxx.xxx.xxx
2026-xx-xx xx:xx:xx cleaning up after signal PIPE
2026-xx-xx xx:xx:xx restore failed (aborted by signal=PIPE)
and:
2026-xx-xx xx:xx:xx restore started below directory /home/samba1/.local/share/containers/storage/volumes/homes to host xxx.xxx.xxx.xxx
2026-xx-xx xx:xx:xx restore failed (Unable to read 4 bytes)
Could this be related to ACL / extended attribute conflicts, active file locks while the Samba container is running, or subuid/subgid mapping issues when rsync attempts to write back into the namespace via podman unshare?
Has anyone encountered this or found a safe way to handle restores with this setup?
Good work getting the backup side solid. The restore errors you’re seeing (aborted by signal=PIPE, Unable to read 4 bytes) are rsync’s protocol desync symptoms — they happen when something writes non-protocol bytes onto stdout of the “remote” rsync process, corrupting the binary stream BackupPC is reading. That’s consistent with intermittent failures: it only breaks when the interference happens to occur mid-transfer.
A few things worth checking, in order of likelihood:
Stray stdout output from the wrapper chain.runagent and podman unshare can both print warnings/banners under certain conditions (e.g. namespace setup messages, subuid/subgid range warnings) that go to stdout instead of stderr. Since restore is bidirectional (rsync server writes and reads), any contamination there is far more damaging than on the backup (read-only) path — which would explain why backups are reliable and restores aren’t. Test manually:
and inspect /tmp/raw.out for anything besides pure rsync protocol bytes at the start. Also check whether the samba1 module’s shell profile (.bashrc/.bash_profile//etc/profile.d) echoes anything on non-interactive login — runagent may source it.
ACL/xattr preservation on restore. Backup only reads; restore additionally has to set ACLs/xattrs inside the unshared user namespace, which is a more fragile path under podman unshare’s UID mapping. As a test, try a restore with --no-perms --no-acls --no-xattrs in BackupPC’s restore rsync args (temporarily) and see if the failures disappear — that would confirm it’s an xattr/ACL write failure surfacing as a protocol break rather than a clean rsync error.
Concurrency/timing. If BackupPC runs multiple restore streams in parallel, each spawning its own podman unshare namespace, there can be startup contention. Try a single-threaded restore to rule this out.
Capture more detail with rsync -vvv (or --log-file=/tmp/rsync-restore.log) on the BackupPC side plus journalctl on the NS8 side around the failure timestamp — that’ll show if it’s a killed process (OOM, seccomp denial under the namespace) rather than pure I/O corruption.
My guess is #1 or #2. Let us know what the raw stdout capture shows.