jellyfin-media-permissionslisted

# Jellyfin media permission/metadata troubleshooting Covers a specific, reproducible failure mode: media lands on disk via some sync pipeline (rsync, scp, etc.), Jellyfin's library scan picks up the *filename* fine, but the file is unreadable by the Jellyfin service account — surfacing as a playback error and/or a stub library entry with no real metadata. First hit 2026-07-17 debugging a movie synced in over the Jellyfin dropbox-sync pipeline (see the homelab project's own memory for that pipeline's specifics); the underlying mechanism generalizes to any media-server-behind-a-sync-job setup. ## The macOS rsync root cause macOS's built-in `rsync` is **openrsync** (protocol 29), not classic GPL rsync — check with `rsync --version`. It has **no `--chown`, `--no-owner`, or `--no-group` flags**. `-a` (archive) still preserves the local macOS account's uid/gid and file mode verbatim onto the remote side. If the source file has a restrictive mode (`600`, owner-only — common for browser downloads, which often carry a quarantine xattr too) and the remote consumer runs as a *different* service account (e.g. `jellyfin`, not the account that owns the transferred bytes), that account can't read it. **This is silent on the sync side** — rsync exits 0, the transfer looks completely successful — and only manifests as an error on the Jellyfin side, often much later when someone tries to play the file. Because there's no rsync flag to fix this from the macOS end, fix it with a **post-trans