[2026-09-20] eagle: personal/tech/xray-reverse-tunnel-kraken-truenas.md

personal/tech/xray-reverse-tunnel-kraken-truenas.md

@@ -89,6 +89,48 @@ verified_fix_2026_09_02: >-
 > - Полные параметры и pitfalls (вкл. удаление `allowInsecure` в Xray 26.7.28) — в `family/how-to/truenas-infrastructure.md`, раздел `xray-admin`.
 > - Reverse к Kraken — это ОТДЕЛЬНЫЙ механизм (для проксирования локальных клиентов сети TrueNAS через Kraken-egress). Он теперь также внедрён и проверен; см. «Верифицированный фикс». 3x-ui-сервер остаётся независимым рабочим VPN-выходом через TrueNAS.
 
+> ## 🔴 2026-09-20 — ВЕРХНЯЯ ТОЧКА ВХОДА: оба туннеля были down из-за ГОНКИ DOCKER↔СМОНТИРОВАНИЕ ДИСКА. ФИКС ПРИМЕНЁН.
+>
+> **Симптом:** `vless reverse proxy kraken→truenas` не работает И `cloudflared ssh tunnel` down. Kraken доступен по LAN (`192.168.1.15`, hostname `kraken`).
+>
+> **Корень — НЕ конфиги Xray и НЕ cloudflared. Одна причина на оба симптома:**
+> `dockerd` стартовал **раньше**, чем монтировался USB-диск с `docker-data`, и загружал пустое состояние → 0 контейнеров в памяти.
+>
+> | Событие | Время (boot Sep 15) |
+> |---|---|
+> | Boot Kraken | 17:29:17 |
+> | `sda1` виден ядром | +130 с → 17:31:27 |
+> | **dockerd PID 1324 стартовал** | **17:31:01** ← на 26 с РАНЬШЕ диска |
+> | Диск смонтирован | 17:31:27 |
+>
+> **Почему оба туннеля:** `cloudflared` и `xray-reverse-bridge` просто не были загружены. Не падали — их не существовало для daemon.
+>
+> **Ничего не потеряно:** `containers/` = 4.7G, **35 контейнеров целы**, образы, 32 volume. Daemon их просто не видел.
+>
+> **Диагностический признак (запомнить):** `docker ps -a` пусто, но `docker-data/containers/` полон → это **всегда** гонка data-root, а не потеря данных. Проверять: `docker info --format "{{.DockerRootDir}} | containers={{.Containers}}"` vs содержимое `docker-data/containers/`.
+>
+> ### ✅ ФИКС (применён, проверен)
+> 1. **Backup:** `/home/kraken/backups/docker-recovery-20260920-105228/` (fstab, daemon.json, xray-reverse).
+> 2. **Немедленно:** `sudo systemctl restart docker` → диск уже смонтирован → все контейнеры загрузились.
+> 3. **Защита от повтора при reboot** — создан drop-in `/etc/systemd/system/docker.service.d/mounts.conf`:
+>    ```ini
+>    [Unit]
+>    RequiresMountsFor=/srv/dev-disk-by-uuid-6194539b-03e0-4f33-986b-4da09834e82f/docker-data
+>    After=srv-dev\x2ddisk\x2dby\x2duuid\x2d6194539b\x2d03e0\x2d4f33\x2d986b\x2d4da09834e82f.mount
+>    ```
+>    Проверено: `systemctl show docker -p Requires -p After` → маунт-юнит в **Requires И After**. dockerd физически не стартует раньше диска.
+> 4. **fstab** — убран ДУБЛЬ строки для 6194539b (внизу была ручная `UUID=6194539b...` вне OMV-блока → «Duplicate entry in fstab» в journal) и дубль bind-mount `/var/log/journal`. Осталось 1 вхождение (OMV-блок). Грепом проверено.
+>
+> ### Проверка после фикса
+> `sudo systemctl restart docker` → `containers=25`, 11-12 Up. Критичные поднялись автоматом: cloudflared, xray-reverse-bridge, jellyfin, sonarr, radarr, prowlarr, portainer, transmission, rclone, watchtower, flaresolverr.
+> ⚠️ `hermes-kraken` — `Restarting (1)` (crash-loop, не связан с этой задачей, был до правок).
+>
+> **Питфолл:** `RestartPolicy` в `hostconfig.json` показывает `null` (reflection исходного `docker run`), но в state policy есть — при рестарте daemon контейнеры поднимаются сами. Не пугаться `null`.
+>
+> **Питфолл диагностики:** `ls docker-data` требует sudo (root:root 711). `sudo -n` работает без апрува — использован `sudo -n ls/jq`.
+>
+> **Урок:** USB-диск на этом узле поднимается ~130 с. Любой сервис, зависящий от `docker-data` на этом диске, ОБЯЗАН иметь `RequiresMountsFor`. Без него — та же гонка.
+
 ## Контекст / Почему
 
 - **VPS qentra.top (91.207.28.205) УДАЛЁН** — вся прежняя Xray-инфраструктура на нём (VLESS+REALITY, OpenVPN, WebSocket v.qentra.top) больше не существует.