# 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)     |

> ⚠️ **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/plans/t610-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/plans/t610-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/plans/t610-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`) |

## 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/