304 lines
25 KiB
Markdown
Executable File
304 lines
25 KiB
Markdown
Executable File
# 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/
|