Files
obsidian-vault/family/documents/vault-sync/2026-09-02-restore-privilege-scope.md
T

7.7 KiB
Raw Blame History

tags, created, status
tags created status
truenas
restore
incident
git
media
arr
permission
2026-09-02 diagnosed

Incident 2026-09-02: Поломка прав uid 921/0000 после restore — масштаб и влияния

Сводный инцидент-документ. Родитель: 2026-08-31-syncthing-truenas-incident.md (Syncthing). Здесь документируем подтверждённый масштаб той же поломки прав и её воздействие на git-sync (мак/Eagle) и медиа/arr-стек на TrueNAS.

Корень (общий для всех): после восстановления из бэкапа /mnt/RED_2TB/storage/* стал принадлежать uid 921 = transmission с правами ----------/d--------- (0000), вместо truenas_admin (950). Контейнеры, пользователи и git, работающие под другими uid, теряют доступ.


1. Git-sync obsidian на маке (Eagle) — СТОИТ (ahead 55)

Симптом на ~/obsidian:

git status       → ## main...nas/main [ahead 55]
git fetch/push   → fatal: '/mnt/RED_2TB/storage/git/obsidian-vault.git' does not appear to be a git repository

Причина (read-only проверка TrueNAS):

/mnt/RED_2TB/storage/git                          d--------- 4 921 921
/mnt/RED_2TB/storage/git/obsidian-vault.git       (permission denied — вложено в storage/git)

Папка storage/git/ (внутри — bare repo obsidian-vault.git) с правами 0000 / owner 921. Git на маке (SSH-ключ жив, CONN_OK ) не может открыть bare repo → fetch/push падают → локальные 55 коммитов не уходят.

Важно про механизм cron — НЕ Hermes cron, а launchd:

  • Агент: ~/Library/LaunchAgents/com.sync-vault.plist
  • Программа: /Users/admin/scripts/sync-vault.sh, StartInterval = 300 сек (5 мин)
  • Состояние: активен (launchctl listcom.sync-vault), runs = 3762, last exit code = 0
  • sync-vault-lib.sh умышленно глушит недоступность remote: если git fetch падает → логирует и exit 0. Поэтому launchd показывает exit code 0 при фактически сломанном sync (ahead 55). Это не сбой cron — это корректное поведение скрипта, скрывающее dead remote.
  • Системный crontab на маке пуст (crontab -l нет), /etc/crontab нет. Запуск — только через launchd ${LABEL}.

Связанные доки: family/how-to/vault-git-sync.md, family/how-to/obsidian-sync.md.


2. Медиа-папки TrueNAS — сломаны (uid 921, d---------/drwx------)

Read-only проверка ls -ld /mnt/RED_2TB/storage/:

d---------  transmission transmission  storage/Cartoons
d---------  transmission transmission  storage/Downloads
d---------  transmission transmission  storage/Movies
d---------  transmission transmission  storage/Music
drwx------  transmission transmission  storage/series
d---------  transmission transmission  storage/shared

(отображается как transmission = uid 921 — тот же, что и в инциденте; права 0000/700 сломаны для внешних сервисов.) Movies-Radarr, Series-Sonarr — не существуют (старая схема, на TrueNAS актуальны только storage/-медиа).

Медиа-папки починки не проходили (в отличие от obsidian/obsidian-syncthing).


3. Arr/Jellyfin-стек на TrueNAS — выключен + не сможет работать из-за прав

Факты:

  • В docker ps -a НЕТ ни radarr/sonarr/prowlarr/jellyfin контейнеров (ни запущенных, ни остановленных). Стек не пересоздавался после проблемного периода.
  • Composes живут в /mnt/RED_2TB/docker/arr/: docker-compose.yml (prowlarr/radarr/sonarr/jellyfin), подпапки prowlarr/ radarr/ sonarr/ jellyfin/ media-pipeline/.
  • docker/arr/docker-compose.yml монтирует /mnt/RED_2TB/storage в radarr/sonarr (rw) и jellyfin (:ro). При сломанных правах медиа-папок контейнеры не смогут читать/импортировать → пустая библиотека.
  • Работает только transmission (Up 8 days), его compose отдельный: /mnt/RED_2TB/docker/transmission/. config владелец transdamon/911. RPC transmission-remote вернул 403 Forbidden — auth вкл., статус торрентов извне без токена не читается.

Чтобы запустить стек: восстановить права медиа-папок storage/ (150 и выше 950/нужный сервисный uid, rwX) → cd /mnt/RED_2TB/docker/arr && docker compose up -d.

Дексо стек — разделение ролей (см. family/how-to/arr-stack-taiga.md):

  • Taiga (TrueNAS) = acquisition (transmission качает, arr добавляет)
  • Kraken = serving (jellyfin на план-сервире). Jellyfin на TrueNAS — acquisition-side media storage, не primary serving.

4. Несвязанные находки (не трогала диагностика, для контекста)

  • Контейнер library-app (library) в restart-loop: FileNotFoundError: '/library/flibusta_fb2_local.inpx' — это приложение полки книг Flibusta, монтирует /mnt/RED_2TB/storage/Downloads/fb2.Flibusta.Net → /library; INPX-файла на пути нет. Не связано с поломкой прав; ручной фикс только по запросу.

Общий план (НЕ выполнен — требует подтверждения + бэкап ACL, единый по всем каталогам)

# 1. Бэкап текущих ACL всех затронутых
getfacl -R /mnt/RED_2TB/storage > /mnt/RED_2TB/backup/_acl_storage_$(date +%F).facl

# 2а. bare git repo (восстановить git-sync на маке)
sudo chown -R 950:950 /mnt/RED_2TB/storage/git
sudo chmod -R u+rwX,g+rwX /mnt/RED_2TB/storage/git
#  → на маке: bash ~/scripts/sync-vault.sh  (55 коммитов уедут)

# 2б. медиа-папки (чтобы arr/jellyfin заработал)
sudo chown -R 950:950 /mnt/RED_2TB/storage/{Movies,Cartoons,Downloads,Music,series,shared,...}
sudo chmod -R u+rwX,g+rwX /mnt/RED_2TB/storage/{Movies,Cartoons,Downloads,Music,series,shared,...}

# 3. Запуск arr-стека
cd /mnt/RED_2TB/docker/arr && docker compose up -d

⚠️ Перед выполнением сверить фактического владельца/права у каждого пути и какие uid-сервисы должны читать. Не менять вслепую — сначала уточнить exact mount/service scopes.

Связанные заметки