Nightly backups to a mounted NAS share ran from May and then stopped, failing
with [Errno 30] Read-only file system. The reporter checked folder permissions
-- correctly: the mount is gid=backup,dir_mode=0775, the service user is in that
group, and his own shell writes to the share fine.
Errno 30 is EROFS. A permission problem is errno 13. EROFS means the filesystem
refused the write, and it refused because we told it to: our systemd unit ships
ProtectSystem=strict, which mounts everything read-only inside the service's
mount namespace and carves back out only ReadWritePaths=<install> <data> <logs>.
A NAS share is not one of those three. Reads are unaffected -- which is why the
UI happily listed his existing backups from the share while being unable to
write a new one -- and his shell is outside the namespace entirely, so every
check he could think to run said the directory was fine.
Both installers write the unit file wholesale, so a ReadWritePaths line added by
hand disappeared on the next install, taking the backups with it. They now back
the old unit up (.bak-<timestamp>) and carry the operator's extra writable paths
forward, reporting which ones they kept. The unit template documents the
carve-out.
The output directory is probed with a real write when it is saved and when the
backup card loads, so an unwritable path is caught there rather than at 03:00
for a week. On failure the card names the cause and hands over the fix with the
operator's path already in it (systemctl edit bambuddy -> ReadWritePaths=...),
and a failed run reports the same diagnosis rather than the raw OSError. EROFS
outside systemd, permission-denied, out-of-space, not-a-directory and missing are
told apart, in all 11 locales.
Docker: a backup path that is not bind-mounted is writable -- the write lands in
the container's ephemeral layer and is lost on the next compose up. The probe
compares the directory's device against the container root and warns, with the
compose snippet that mounts it properly.
The Scheduled Local Backups time-of-day picker was interpreted as UTC by
_calculate_next_run, so a UTC+3 user had to enter 18:00 to get a 21:00
local backup. The UI labeled the field "UTC" but it was still surprising.
Picker is now interpreted in the container's local timezone, resolved
from the TZ env var via zoneinfo.ZoneInfo (same source the Support page's
environment.timezone shows). UTC fallback when TZ is unset or
unrecognised. The /local-backup/status endpoint exposes the resolved
zone, and the UI renders it next to the field via a new
backup.localTimeHint i18n key with real translations in all 10
non-English locales.
One-time behaviour change for users who entered a UTC time as a
workaround: the first scheduled cycle after upgrade will run at their
local TZ offset earlier than expected. Re-enter the time as local once
and it is correct from then on. No migration is shipped; migrating
around a DST boundary would be ambiguous.
maziggy