mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-06 10:59:59 +00:00
kevinveenbirkenbachandClaude Opus 5.5
b894db0a75
rsync 3.5.0 (Debian security update 3.5.0+ds1-0+deb13u1) refuses a destination symlink owned by neither root nor the calling user. svc-opt-ssd-hdd turns a volume's `_data` into a symlink to /mnt/hdd or /mnt/ssd. The restore drill empties the volume and runs `compose create`; docker repopulates it and lchowns the `_data` symlink to the image directory's owner (e.g. www-data). The restore then failed with "refusing to follow a symlink owned by an untrusted user" and "change_dir#1 .../_data/ failed: Too many levels of symbolic links", the drill left its subjects down, and the dependent checks timed out (CI run 40979252521, ssd-hdd#0, on feature/store-i18n; recover.py is identical on main). VolumeRecovery now resolves the mountpoint before handing it to rsync: os.path.realpath locally, `ssh <host> realpath -e -- <mountpoint>` for --docker-host, so rsync writes into the real directory and never meets the symlink. `--insecure-links` was not used because older rsync builds on other distributions lack it. Two new unit tests (local symlinked mountpoint, remote resolution); both fail against the previous code. Root cause and fix by the i18n session (feature/store-i18n triage of ssd-hdd#0), ported to main. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>