obsidian-vault/family/how-to/truenas-access.md

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)

# 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 контактов, разные ключи). Перенос планок невозможен ни в одну сторону.

Подключение

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

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

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 на роутер:

# через 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 "команда"'

Проверка правил форвардинга портов:

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"'

Добавление правила порт-форвардинга:

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

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

# с 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:

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)

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/