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)

Доступ к /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:

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/