[2026-09-02] eagle: family/documents/vault-sync/2026-09-02-restore-privilege-scope.md family/how-to/arr-stack-taiga.md family/how-to/obsidian-sync.md family/how-to/truenas-infrastructure.md family/how-to/vault-git-sync.md

family/how-to/arr-stack-taiga.md

@@ -17,6 +17,10 @@ Secondary arr stack on Taiga (TrueNAS), added 2026-05-20.
 >
 > **Почему не запускается просто так — медиа-права сломаны** (тот же restore-инцидент uid 921/0000): `/mnt/RED_2TB/storage/{Movies,Cartoons,Downloads,Music,series,shared}` → `d---------`/`drwx------`, owner `transmission` (uid 921). radarr/sonarr монтируют `/storage` (rw), jellyfin `:ro` — со сломанными правами не прочитают библиотеку. Фикс + запуск: см. `family/documents/vault-sync/2026-09-02-restore-privilege-scope.md`.
 
+> **Docker-image facts (2026-09-02):** All 5 media images **loaded locally** on TrueNAS (`docker images`): `lscr.io/linuxserver/{radarr,sonarr,jellyfin,transmission,prowlarr}:latest`. Only **transmission** container exists (running). **jellyfin/radarr/sonarr/prowlarr containers are NOT yet created** — they never get launched until perms fixed.
+> **Transmission runs as ROOT** (not 911/950): its compose `/mnt/RED_2TB/docker/transmission/docker-compose.yml` has **no `PUID`/`PGID`**, so linuxserver `/init` (s6-overlay) leaves it root (`docker exec transmission id` → uid 0). This is why it works on the 0000 media dirs. It mounts `storage` → `/mnt/storage`, download-dir = `/mnt/storage/Downloads`.
+> **Fix direction (approved Variant A):** set `PUID=950 PGID=950` on transmission + all arr/jellyfin compose services so every service shares uid `950` and mutually reads files; then recursively fix perms in depth. Plan + commands: `2026-09-02-restore-privilege-scope.md` §5.
+
 ## Notes from Setup (2026-05-20)
 
 - Config and pitfalls recorded during initial Taiga arr stack deployment

family/how-to/obsidian-sync.md

@@ -34,7 +34,7 @@ mallexxx.duckdns.org:/mnt/RED_2TB/storage/git/obsidian-vault.git
 
 | Узел | Vault путь | Scope | Скрипт | Крон |
 |------|-----------|-------|--------|------|
-| Eagle | `~/obsidian` | full vault | `~/scripts/sync-vault.sh` | `0 * * * *` (Hermes cron job) |
+| Eagle | `~/obsidian` | full vault | `~/scripts/sync-vault.sh` | **launchd `com.sync-vault`** (5 мин; ⚠️ НЕ Hermes cron — см. `vault-git-sync.md` §Scripts) |
 | Kraken | `~/obsidian` | sparse: `personal/ family/` | `~/scripts/sync-vault.sh` | `0 * * * *` (crontab) |
 | Taiga | `/mnt/RED_2TB/docker/hermes/vault` | sparse: `personal/ family/` | `~/sync-vault.sh` (на хосте!) | `0 * * * *` (Hermes cron job) |
 

family/how-to/truenas-infrastructure.md

@@ -169,10 +169,12 @@ arr, caddy, cups, filebrowser, gitea, hermes, immich, inpx-web, inpxer, library,
 6. **Проверка:** `docker ps`. HA: `docker exec homeassistant python -m homeassistant --script check_config --config /config`.
 
 ### Transmission — детали
-- **Config:** `/mnt/RED_2TB/docker/transmission/` (монтируется как `/config`)
+- **Config:** `/mnt/RED_2TB/docker/transmission/` (монтируется как `/config`; внутри `/config/docker-compose.yml`)
 - **Данные:** `/mnt/RED_2TB/storage` (монтируется как `/mnt/storage`)
 - **Download dir:** `/mnt/storage/Downloads`
-- **UID/GID:** 911/911 (пользователь `transdamon`)
+- **UID/GID:** ⚠️ **по факту работает как ROOT (uid 0)**, НЕ 911/911. Причина: в `/mnt/RED_2TB/docker/transmission/docker-compose.yml` **НЕ задан `PUID`/`PGID`** → linuxserver `/init` (s6-overlay) оставляет контейнер root (подтверждено `docker exec transmission id` → root). Пользователь `transdamon`/911 (док) — это владелец конфига на хосте (`drwx------ 911 911`), но НЕ процесс внутри контейнера.
+  - **Зачем важно:** root-трансмишен пишет файлы как root и переживает права 0000 медиа → это причина, почему он "работает" на сломанных после restore папках. Но для pipeline с jellyfin/radarr (не-root) root-создаваемые файлы барьер.
+  - **План фикса (Вариант A, одобрен 2026-09-02):** добавить `PUID=950 PGID=950` и пересоздать контейнер → работает под `truenas_admin`. План: `family/documents/vault-sync/2026-09-02-restore-privilege-scope.md` §5.
 - **RPC whitelist:** `172.16.6.*`
 - **Web:** https://transmission.mallexxx.duckdns.org
 - **Порты:** 9091 (RPC/web), 51413 (TCP/UDP peers)

family/how-to/vault-git-sync.md

@@ -54,10 +54,16 @@ No stash. No GIT_DIR/GIT_WORK_TREE workarounds.
 
 | Host   | Script                        | Type          | Trigger              |
 |--------|-------------------------------|---------------|----------------------|
-| Eagle  | `~/scripts/sync-vault.sh`     | full clone    | Hermes cron */5      |
+| Eagle  | `~/scripts/sync-vault.sh`     | full clone    | **launchd** `com.sync-vault` (⚠️ НЕ Hermes cron) `StartInterval=300` |
 | Kraken | `~/scripts/sync-vault.sh`     | sparse clone  | host crontab */5     |
 | Taiga  | `/opt/data/sync-vault.sh`     | 3-phase orch. | Hermes cron */5      |
 
+> **⭐ УТОЧНЕНО 2026-09-02 (Eagle/мак sync-механизм):** автосинка на маке запускается **НЕ Hermes cron, а launchd-агентом** `~/Library/LaunchAgents/com.sync-vault.plist`:
+> - Программа: `/Users/admin/scripts/sync-vault.sh`, `StartInterval = 300` сек (5 мин)
+> - `launchctl list` → активен, `runs = 3762`, `last exit code = 0`
+> - ⚠️ **`sync-vault-lib.sh` умышленно глушит недоступность remote**: если `git fetch` падает → логирует `Fetch failed (...)` и `exit 0`. Поэтому launchd показывает `exit code 0`, даже когда sync фактически сломан (см. случай ahead 55 при сломанном bare repo после restore). Это **не** отсутствие cron и не сбой — диагностировать нужно по `git status` (ahead count), а не по exit-code агента.
+> - Системный crontab и `/etc/crontab` на маке отсутствуют.
+
 All clients share a common library: `sync-vault-lib.sh` (same dir as sync-vault.sh).
 Source of truth for scripts: `~/Developer/vault-sync-test/scripts/` on Eagle.