# TrueNAS — Домашний NAS

## Основное

| Параметр | Значение                           |
|----------|------------------------------------|
| Версия   | TrueNAS SCALE 24.10                |
| CPU      | Intel Pentium G2020 @ 2.90 ГГц (2 ядра / 2 потока, Ivy Bridge, LGA1155) |
| RAM      | 21 ГБ DDR3                         |
| Мать     | ASUS P8H77-V LE (чипсет Intel H77) |
| Web UI   | https://mallexxx.duckdns.org       |
| Web UI (IP) | http://90.189.160.148           |
| SSH      | truenas_admin@mallexxx.duckdns.org |
| SSH (IP) | truenas_admin@90.189.160.148       |
| SSH-ключ | ~/.ssh/id_rsa                      |
| Сеть     | 192.168.2.0/24 (через OpenWrt)     |

> 🔴 **ПИТФОЛЛ (2026-09-26): хост НЕ в `~/.ssh/config` — писать полный адрес.**
> `ssh truenas`, `ssh nas`, `ssh truenas.local`, `ssh 192.168.1.100` — **все fail** (NF/timeout,
> 192.168.1.x — чужая подсеть, см. ниже). Агент принял это за «NAS недоступен» и объявил блокер —
> **ложно**. Рабочий вызов: `ssh truenas_admin@mallexxx.duckdns.org`. **Читать эту таблицу,
> а не перебирать имена по памяти.**
>
> ✅ **`python3` на ХОСТЕ NAS есть (3.11.9)** — можно запускать парсеры ID3 прямо на NAS:
> `scp id3_direct.py truenas_admin@mallexxx.duckdns.org:/tmp/` → `ssh … 'python3 /tmp/id3_direct.py --file "<путь>"'`.
> (В контейнере `jellyfin` python3 НЕТ — не путать хост и контейнер.)

> ⚠️ **Eagle и Kraken — в 192.168.1.x, это другая сеть.** Прямой доступ по 192.168.2.197 с них не работает. Для SSH/API с Eagle и Kraken используйте **только** `mallexxx.duckdns.org`.
>
> 📝 Наблюдение 2026-07-31: `ssh truenas_admin@192.168.2.197` **сработал с Mac Кита (Кит)** в ходе диагностики SATA-карты (по явной просьбе Alex). Т.е. локальный IP может работать, но это не гарантировано — при неудаче откатываться на `mallexxx.duckdns.org`.

> 🔑 **У `truenas_admin` НЕТ приватных ключей** (`~/.ssh` = только `authorized_keys` + `known_hosts`) — это **норма**, не поломка. Следствия:
> - `truenas_admin` **не может** зайти по SSH на t610 (`Permission denied (publickey)`) — ключа нет. Вход NAS→t610 настроен **от юзера `nas`**, служебным ключом бэкапа (`/mnt/RED_2TB/backup/t610/.ssh/id_ed25519`). См. [[family/plans/t610-backup-to-truenas]] питфолл №1.
> - `sudo -u nas …` от `truenas_admin` **требует пароля** (`a password is required`) — проверить pull-ключ можно только под root-shell (у Alex он есть).
> - 🔴 **Не делать вывод «ключа/доступа нет» по `ls ~/.ssh` одного пользователя** — смотреть владельца и путь из скрипта-потребителя.

### Как проверить сетевой путь NAS → t610 (канон, 2026-09-14)

```bash
# 1) каким src-адресом NAS уйдёт на t610 (важно для from="..." ограничений в authorized_keys)
ip route get 192.168.2.176        # → dev enp3s0 src 192.168.2.197
# 2) порт 22 на t610 со стороны NAS (у truenas_admin есть nc)
nc -w 3 -z 192.168.2.176 22 && echo PORT22_OPEN
# 3) TCP-forwarding на sshd TrueNAS — ЗАПРЕЩЁН, поэтому `ssh -J truenas …` не работает
#    (проверять конфиг под своим пользователем: sshd -T | grep allowtcpforwarding)
```

> ⚠️ **`nc -z` на t610 с NAS = только «порт открыт»**, это НЕ доказательство доступа (аутентификация отдельно).
> ⚠️ **`macOS → t610` напрямую по `192.168.2.176` — таймаут** (Mac в другой подсети). Единственный путь с Mac на t610 — через локалку/NAT, см. [[family/how-to/home-automation]] §2 «Доступ».

## Железо (проверено 2026-09-10, `lscpu` + `free -h` на живом хосте)

| Параметр | Значение |
|----------|----------|
| Материнская плата | ASUS P8H77-V LE (чипсет Intel H77, LGA1155) |
| CPU | **Intel Pentium G2020 @ 2.90 ГГц** (2 ядра / 2 потока, Ivy Bridge, 2013) |
| RAM | **21 ГБ DDR3** (на 2026-09-10: занято 17 ГБ, free 1.8 ГБ, buff/cache 3.2 ГБ, available 3.6 ГБ) |
| Swap | 0 B (не используется) |
| Диски | см. [[truenas-sata-ports-and-zfs-pools]] |

> 📌 До 2026-09-10 CPU/RAM в доке **отсутствовали** — при вопросах о производительности/совместимости приходилось выяснять заново. Теперь зафиксировано.
>
> ⚠️ **RAM 21 ГБ нестандартна для LGA1155** — на P8H77-V LE стоят планки разного объёма (flex mode). Проверять при апгрейде.
>
> **Следствие по нагрузке:** занято 17 из 21 ГБ → узел работает **на пределе по памяти, не по CPU**. Именно RAM (21 ГБ), а не процессор — причина, по которой тут крутятся immich + HA + ~25 контейнеров + ZFS-кэш. CPU G2020 — узкое место только в single-thread-задачах.

### Производительность в сравнении (2026-09-10)

| Узел | CPU | PassMark (сумма) | Single-thread | RAM | TDP |
|------|-----|------------------|---------------|-----|-----|
| TrueNAS (Таёга) | 2× Pentium G2020 @2.9 | ~1700 | ~1400 | 21 ГБ DDR3 | 55 Вт |
| RPi4 4GB (Кракен) | 4× Cortex-A72 @1.5 | ~1900 | ~750 | 4 ГБ LPDDR4 | 5–7 Вт |
| HP t610 | 2× AMD T56N @1.65 | ~850 | ~450 | 4 ГБ DDR3 | 9–15 Вт |

**Выводы:**
- TrueNAS ≈ RPi4 по многопотоку (2 ядра против 4), но **вдвое выше в single-thread**. Сервисы HA/Node-RED/БД single-thread-зависимы → здесь TrueNAS выигрывает.
- **HP t610 — вдвое слабее обоих** (2011, Bobcat-ядро). Единственный плюс — x86-64, официальные образы встают без возни с ARM.
  - 📌 **2026-09-12: t610 назначен хостом домашней автоматизации.** Перенос **выполнен 2026-09-14** — см. [[family/how-to/home-automation]]. RAM 4 ГБ и HDD достаточны.
- **Jellyfin-транскод не тянет никто** из трёх (iGPU HD2500 у G2020 без современного кодека; RPi4/t610 — нет аппаратного пути).

### Совместимость с DDR/DDR2 из гаража

Платы из гаража ([[family/documents/garage-lucky-park]]) несут **DDR 333/400** и **DDR2 533/667**; TrueNAS (P8H77-V LE) — **DDR3**. Три поколения, физически и электрически несовместимы (184 / 240 / 240 контактов, разные ключи). **Перенос планок невозможен ни в одну сторону.**

## Подключение

```bash
ssh -i ~/.ssh/id_rsa truenas_admin@mallexxx.duckdns.org
```

### Снятие железа (рецепт, если понадобится снова)

```bash
ssh -i ~/.ssh/id_rsa truenas_admin@mallexxx.duckdns.org \
  'lscpu | grep -iE "model name|^CPU\(s\)|MHz|socket|core|thread"; free -h'
```
> `dmidecode -t 17` требует root — `truenas_admin` не имеет passwordless sudo, вернёт пусто. CPU/RAM берутся из `lscpu` + `free -h` без root.

## OpenWrt — доступ с TrueNAS

**SSH на роутер:**
```bash
# через docker-контейнер с sshpass
docker run --rm alpine sh -c 'apk add -q openssh sshpass && sshpass -p 1316261 ssh -o StrictHostKeyChecking=no root@192.168.2.2 "команда"'
```

**Проверка правил форвардинга портов:**
```bash
docker run --rm alpine sh -c 'apk add -q openssh sshpass && sshpass -p 1316261 ssh -o StrictHostKeyChecking=no root@192.168.2.2 "uci show firewall | grep redirect"'
```

**Добавление правила порт-форвардинга:**
```bash
docker run --rm alpine sh -c 'apk add -q openssh sshpass && sshpass -p 1316261 ssh -o StrictHostKeyChecking=no root@192.168.2.2 "uci add firewall redirect && uci set firewall.@redirect[-1].name=ИМЯ && uci set firewall.@redirect[-1].proto=tcpudp && uci set firewall.@redirect[-1].src=wan && uci set firewall.@redirect[-1].src_dport=ПОРТ && uci set firewall.@redirect[-1].dest=lan && uci set firewall.@redirect[-1].dest_ip=192.168.2.197 && uci set firewall.@redirect[-1].dest_port=ПОРТ && uci set firewall.@redirect[-1].target=DNAT && uci commit firewall && /etc/init.d/firewall reload"'
```

**Пароль root:** `1316261`

> ⚠️ **ВАЖНО (2026-09-14):** `1316261` — пароль **только от OpenWrt-роутера `192.168.2.2`**. Это **НЕ пароль от TrueNAS** (Alex: «Это не пароль от truenas»). Не использовать его для root-операций на TrueNAS.
>
> 🔑 **Root-операции на TrueNAS делать через WebUI → System → Shell** — этот шелл работает под root, пароль не требуется. Так сделаны `mkdir -p /mnt/.ix-apps/app_configs` и `chown nas:nas /mnt/RED_2TB/backup/t610`. `truenas_admin` **не имеет passwordless sudo** (подтверждено многократно).
>
> 🧑 **У Alex ЕСТЬ root-SSH на TrueNAS** (2026-09-14: `root@truenas[/mnt/RED_2TB/backup/t610]#`). Агент не должен предлагать ему WebUI-инструкции, если он уже сказал, что работает под root-shell. Агенту root-SSH **недоступен** — только `truenas_admin`.


> 💡 **Бэкап firewall OpenWrt перед любой правкой redirect-правил** (вошло в практику 2026-09-01):
> ```bash
> # с TrueNAS: сохранить весь firewall-конфиг OpenWrt в backup-папку TrueNAS
> docker run --rm alpine sh -c 'apk add -q openssh sshpass && sshpass -p 1316261 ssh -o StrictHostKeyChecking=no root@192.168.2.2 "uci show firewall"'
> # → сохранить вывод в /mnt/RED_2TB/docker/backups/openwrt-firewall-YYYYMMDD-HHMMSS.txt
> # Пример сделанного: /mnt/RED_2TB/docker/backups/openwrt-firewall-20260901-130558.txt
> ```
> Существующие redirect-правила OpenWrt → TrueNAS(192.168.2.197): MQTT 1883, SSH 22, caddy_http 80→8088, caddy_https 443→8443, HomeAssistant 8123 (disabled).

## Доступ с TrueNAS на другие хосты

### 🔴 ЗАПРЕТ TCP-forwarding на sshd TrueNAS (проверено 2026-09-14)

```bash
# с Mac: попытка прыгнуть через NAS на домашний хост
ssh -J truenas_admin@mallexxx.duckdns.org root@192.168.2.176
→ channel 0: open failed: administratively prohibited: open failed
```
**`AllowTcpForwarding no`** — `-J`/`-L`/`-W` через TrueNAS **не работают**. Обход — только «двойной ssh» без forward:
```bash
ssh -t truenas_admin@mallexxx.duckdns.org ssh root@192.168.2.176
```
> ⚠️ **ПИТФОЛЛ:** `sshd -T | grep allowtcpforwarding` от `truenas_admin` даёт **пусто** (нет прав читать эффективный конфиг). Это **не** признак «forward разрешён» — судить только по факту: ошибка `administratively prohibited` = закрыт.

### NAS → t610 (HA OS): пока НЕТ доступа — ключ ограничен

| Проверка | Результат |
|---|---|
| Сеть / порт | ✅ `nc -w 3 -z 192.168.2.176 22` → **OPEN** (на NAS `nc` — GNU, `-z` работает) |
| SSH с NAS | ❌ `root@192.168.2.176: Permission denied (publickey)` |

**Причина — не «ключа нет», а ключ непригоден.** На t610 в `authorized_keys` лежит служебный ключ бэкапа `t610-backup-pull` с ограничениями **`from="192.168.2.197"`** + **`no-pty`/`no-port-forwarding`**: NAS стучится изнутри локалки **не как `.197`** → отказ; и даже при совпадении адреса `no-pty` не дал бы интерактивного шелла.

> 📌 **Ключи NAS:** `~truenas_admin/.ssh/` = **только** `authorized_keys` + `known_hosts`, **приватных ключей нет**. Приватный ключ бэкапа лежит в **`/mnt/RED_2TB/backup/t610/.ssh/id_ed25519`** (+ `config` с алиасом `t610-backup`) — не в `~nas/.ssh`.
> 📌 **`authorized_keys` на t610 правится только ИЗНУТРИ t610** (шелл аддона `core_ssh` / UI аддона Terminal & SSH). С NAS — курица и яйцо; практически делать с Mac по локалке: `ssh -i ~/.ssh/id_rsa root@192.168.2.176`.
> 📌 На t610 `/root/.ssh/authorized_keys` и `/data/.ssh/authorized_keys` — **один и тот же файл** (симлинк в аддоне).

**Полный разбор, варианты решения (A/B/C) — §5-кватер-Р** доки [[family/how-to/home-automation]]. Смежный питфолл `from=.197` — №1 доки [[family/plans/t610-backup-to-truenas]].

## Пул и датасеты

Пул: RED_2TB (ZFS)
Точка монтирования: /mnt/RED_2TB/

| Датасет       | Путь                          | Назначение            |
|---------------|-------------------------------|-----------------------|
| storage/      | /mnt/RED_2TB/storage/         | Общее хранилище       |
| backup/       | /mnt/RED_2TB/backup/          | Резервные копии       |
| backup/t610/  | /mnt/RED_2TB/backup/t610/     | **Бэкап конфигов t610** (HA OS), владелец `nas:nas` 770, создан 2026-09-14 — см. [[family/plans/t610-backup-to-truenas]] |
| Photos/       | /mnt/RED_2TB/Photos/          | Фотографии            |
| TimeMachine/  | /mnt/RED_2TB/TimeMachine/     | Бэкапы macOS          |
| Edu/          | /mnt/RED_2TB/Edu/             | Учебные материалы     |
| storage/git/  | /mnt/RED_2TB/storage/git/     | Git-репозитории       |
| ix-apps/      | /mnt/.ix-apps/                | Docker data-root (`docker.config.dataset=RED_2TB/ix-apps`) |

## Доступ к `/mnt/RED_2TB/Edu` — группа `nas_users` (2026-09-23)

**Было:** `Edu` и `Edu/Маскелиаде` недоступны и по WebDAV, и по SSH от `truenas_admin` —
файлы `root:root`, режим `rwxrwx---`, `group@` указывал на gid 0, а `truenas_admin` в gid 0 не
входит. Внутри лежали объекты от трёх разных владельцев (`mallexxx`, `nas:nas_users`, `root`).

**Сделано:** рекурсивно, два прохода `midclt call filesystem.setacl` (не `chgrp` — под
`truenas_admin` он даёт `Operation not permitted`):

1. `dacl` = все ACE с `{"BASIC":"INHERIT"}`, `group@` → `ALLOW` + полный набор прав;
2. `gid=3000` (`nas_users`) рекурсивно, `uid` без изменений.

🔴 **Ключевое:** `group@` в NFSv4 — это **POSIX-gid файла**, а не самостоятельная запись.
Одного ACE с INHERIT **недостаточно**: без смены `gid` он матчит старую группу и не даёт ничего.

**Проверено:**
- `Edu` → `drwxrwxr-x root:nas_users`, `gid=3000`, содержимое листится от `truenas_admin`;
- `Маскелиаде`, `Книги, учебники` → `gid=3000`, все ACE `INHERITED: True`;
- `touch` в `Edu` → `WRITE_OK`.

**Группа `nas_users` (gid 3000):** `root`, `truenas_admin`, `mallexxx`, `nas`, `transmission` —
одна запись покрывает всех. Полный состав прав `truenas_admin`:
```bash
id truenas_admin
# uid=950 gid=950 groups=950,544(builtin_administrators),921(transmission),
#                       999(docker),1000(nas),3000(nas_users)
```

**Артефакты:** бэкап ACL до правки — `/mnt/RED_2TB/storage/acl-edu-before-20260922-234617.json`;
скрипты — `/mnt/RED_2TB/storage/edu_acl_fix.py`, `/mnt/RED_2TB/storage/edu_chgrp_fix.py`
(копии на Mac: `~/tmp/`). Подробный рецепт — [[personal/tech/truenas-nfs4-acl-and-arrmultiuser]]
§«Sharing a whole tree by GROUP».

> ⚠️ **Кириллица в путях (`Edu/Маскелиаде`) блокируется сканером** как `confusable_text` (HIGH)
> — дважды срывала команды. Пути брать в кавычки, кириллицу не стыковать с ASCII в одном слове,
> по возможности обходиться `find -iname`/bare-string в `getacl`.

## Доступ с macOS в Finder — WebDAV vs SMB (2026-09-23)

| Способ | Локалка `192.168.2.x` | Из интернета | Комментарий |
|--------|----------------------|--------------|-------------|
| **SMB** :445 | ✅ нативный, быстрый | ❌ **не проброшен и не надо** | порт 445 — цель сканеров; в OpenWrt его нет |
| **WebDAV** HTTPS | ✅ | ✅ | `https://webdav.mallexxx.duckdns.org`; Finder медленный на больших файлах |
| **NFS** :2049 | ✅ | ❌ | macOS-NFS плохо с кодировками, auth по IP |

**Ответ на вопрос «WebDAV — единственный надёжный способ из Finder?» — нет.**
В локалке SMB надёжнее; WebDAV — то, что у тебя есть для доступа **снаружи** (обёрнут в Caddy +
duckdns). SMB наружу не пробрасывают. Правильный путь «SMB снаружи» — VPN (WG-хаб или
WG-over-Reality), тогда SMB идёт внутри тоннеля.

**SMB-шары на `Edu` НЕТ** — есть только `old-bu`, `storage`, `t610`. Создание шары
(`midclt call sharing.smb.create`, root не нужен) — **не выполнено, ждёт решения Alex**.

📌 **WebDAV-контейнер работает под root** (`docker top webdav` → `root … webdav --config
/config.yml`), поэтому ACL его не блокировал — `owner@` был ALLOW. Образ `hacdias/webdav` —
distroless: `docker exec webdav ls|id|cat` → `executable file not found`. UID смотреть через
`docker top`, не через exec.

## Сервисы `/mnt/RED_2TB/docker/` — инвентарь (2026-09-23)

**VLESS/Xray-семейство:**

| Контейнер | Образ | Роль |
|-----------|-------|------|
| `xray-admin` | `ghcr.io/mhsanaei/3x-ui` | панель 3x-ui, конфиг `/mnt/RED_2TB/docker/xray-admin` |
| `vless-proxy` | `teddysun/xray` | клиент VLESS, туннелирует через `vpn.mallexxx.duckdns.org:443` (Telegram-бот и др.) |
| `xray-reverse-portal` | `teddysun/xray:26.4.25` | **reverse-туннель Кракен→TrueNAS** (inbound `interconn` 12346, VLESS+Reality+vision) |
| `probe-load`/`probe-burst`/`probe-test`/`vless-test` | `ghcr.io/xtls/xray-core` | одноразовые пробы, **Exited** (можно чистить, но только с разрешения) |

**`xray-reverse-portal` (`/mnt/RED_2TB/docker/reverse-portal/config.json`):**
- inbound `interconn` — `0.0.0.0:12346`, VLESS + Reality (`dest www.cloudflare.com:443`,
  `shortId 1451ef281caf5905`), клиент с `reverse.tag = "reverse-out"`;
- inbound `local` — `0.0.0.0:12345`, **SOCKS без аутентификации**, `udp: true`;
- routing: `inboundTag: ["local"] → outboundTag: "reverse-out"`.

🔴 **Это НЕ VPN в домашнюю сеть.** Проверено живьём: SOCKS `12345` слушает, но запрос к
`192.168.2.2` через него → `000`, timeout 12 s. Весь трафик inbound `local` уходит в
`reverse-out` (на Кракена) и выходит **в интернет Кракена**, а не в `192.168.2.0/24`.
Домашняя сеть через туннель **не видна**. VLESS/Xray — прокси уровня приложений: он не даёт
интерфейса, который Finder/SMB понимает как «сеть», и SMB через SOCKS не ходит в принципе.

**Чтобы `192.168.2.x` стали локальными — нужен WireGuard**, варианта два:
1. **WG-over-Reality** — WG-туннель, завёрнутый в уже поднятый VLESS-Reality (обход блокировки
   UDP через TCP/443); минус — MTU-возня, выше задержка;
2. **VPS-хаб** по скиллу `wireguard-vps-hub` — надёжнее, но отдельная инфраструктура.

Статус: **план не выбран, работа не начата** — Alex выбирает вариант.

## SMB-шары (проверено 2026-09-14)

| id | Имя | Путь | Purpose | enabled |
|----|-----|------|---------|---------|
| 1 | `old-bu` | `/mnt/RED_2TB/old-bu` | DEFAULT_SHARE | true |
| 2 | `storage` | `/mnt/RED_2TB/storage` | DEFAULT_SHARE | true |
| 3 | `t610` | `/mnt/RED_2TB/backup/t610` | DEFAULT_SHARE | true |

> 📌 **Шары хранятся в Samba registry, НЕ в `/etc/smb4.conf`.** Файл содержит только `[global]` + `include = registry` + `registry shares = True`. Поэтому `grep`/`testparm` по имени шары **ничего не находят** — это не признак поломки. Проверять: `midclt call sharing.smb.query`.
> 📌 NFS-экспортов на TrueNAS **нет ни одного** (`sharing.nfs.query` пуст). NFS можно экспортировать только с **датасета**, не с подпапки — для шары на подкаталог (как `backup/t610`) годится только SMB.
> 📌 `midclt call sharing.smb.create '{"purpose":"DEFAULT_SHARE","path":"...","name":"..."}'` — создание шары от `truenas_admin` **работает** (root не нужен). Перед правкой делать дамп: `midclt call sharing.smb.query > /mnt/RED_2TB/storage/shares-before-<ts>.json`.

## 🐛 Питфоллы UI и датасетов (2026-09-14)

1. 🔴 **`Failed to load datasets: '/mnt/.ix-apps/app_configs'` — валит ВЕСЬ UI датасетов/Apps.**
   После пересоздания пула каталог `app_configs` не был создан в датасете `ix-apps`. UI читает его безусловно → падает вся страница, невозможно создать датасет/шару. **Choose Pool не помогает.**
   **Фикс (root, WebUI → System → Shell):** `mkdir -p /mnt/.ix-apps/app_configs` → UI оживает. ✅ Проверено.
2. 🔴 **`aclmode: DISCARD aclmode may not be set for NFSv4 acl type`** при создании датасета.
   Пул RED_2TB на `acltype=nfsv4`, где `DISCARD` запрещён. **Фикс:** ACL Mode = **`Passthrough`** (или пусто), ACL Type = `NFSv4`.
3. 🔴 **POSIX `setfacl` на NFSv4-датасете не работает** — `Operation not supported`. Владельца/права менять только через **`chown` под root** или **UI → Datasets → Edit → Permissions/ACL**.
4. ⚠️ **`zfs`/`zpool` не в PATH у `truenas_admin`** — `zfs list` даёт пусто. Вызывать `/sbin/zfs`, `/sbin/zpool`. Иначе кажется, что датасетов нет.
5. ⚠️ **`testparm`/`smbclient -L` от `truenas_admin` не работают** — `regdb_init: Failed to open registry /var/run/samba-cache/registry.tdb (Permission denied)`. Проверка SMB от непривилегированного юзера неинформативна.


## ⚠️ Важно: boot-pool не выживает после обновления

/home и /root находятся на boot-pool и **стираются при обновлении TrueNAS**.

Всё важное (конфиги, ключи, скрипты) должно лежать в /mnt/RED_2TB/,
а не в /home/truenas_admin/ или /root/.

Типичные жертвы:
- SSH authorized_keys в /home
- Cron jobs, написанные в /etc
- Любые файлы вне /mnt/RED_2TB/