Короткий ответ

Сверьте три вещи: путь экспорта (/mnt/tank/share vs /mnt/tank), кто имеет право (сеть 10.0.20.0/24, не только localhost), версию (сервер NFSv4-only, клиент vers=3). На TrueNAS это Sharing → Unix Shares + сеть клиента. На Ubuntu: showmount -e NAS01, rpcinfo, idmapd.conf Domain = тому же, что на NAS01, иначе uid «nobody». Не лечите no_root_squash «чтобы заработало».

Сначала доступен ли NAS по 2049.

Симптомы и как отличить

Типичная картина:

  • mount -t nfs NAS01:/mnt/tank/share /mnt/nfs висит;
  • сразу access denied;
  • монтируется, все файлы nobody:nogroup;
  • Windows NFS клиент vs Linux — разные стеки.
ОшибкаСмысл
timed outсеть, firewall, nfsd не слушает
access deniedexports/сеть/параметры
Protocol not supportedvers/sec
No such fileпуть не экспортирован, пул не смонтирован
Stale file handleпул/export пересоздали, нужен umount/mount

SMB открывается, NFS нет — не «NAS мёртв», а nfsd/export.

Возможные причины

  1. Сеть клиента не в Allowed Hosts.
  2. Неверный mount path (dataset не тот).
  3. NFSv4 vs v3, нет nfs-common / nfs-utils.
  4. idmap Domain mismatch (localdomain vs contoso.example).
  5. Firewall: 2049 есть, для v3 нет rpcbind/mountd динамических портов.
  6. Пул tank не imported — путь пустой.
  7. sec=krb5 на сервере, клиент sys.
  8. После смены fsid — stale на автомонтировании.

Диагностика

1. Порт и rpc

С app01 (Ubuntu):

getent hosts NAS01.contoso.example
nc -vz 10.0.30.10 2049
rpcinfo -p NAS01.contoso.example
showmount -e NAS01.contoso.example

Пустой showmount при живом v4-only — норма. Тогда проверяйте export в UI и nfsstat.

2. Попытка с явными опциями

sudo mkdir -p /mnt/nfs
sudo mount -v -t nfs -o vers=4.1,hard,timeo=60 NAS01.contoso.example:/mnt/tank/share /mnt/nfs
sudo mount -v -t nfs -o vers=3 NAS01.contoso.example:/mnt/tank/share /mnt/nfs

Что проходит — то и зафиксируйте в fstab. Не оставляйте «какая версия выстрелила» без записи.

3. На NAS01 (SCALE)

exportfs -v
cat /etc/exports
zfs list tank/share

Путь должен существовать и быть смонтирован. Сеть: 10.0.20.10 клиента в списке, не только 10.0.30.0/24, если app01 в другом VLAN.

4. idmap NFSv4

grep -i Domain /etc/idmapd.conf
systemctl status nfs-idmapd
ls -ln /mnt/nfs

nobody + верные POSIX на сервере = idmap/домен, не chmod 777.

На TrueNAS: Directory Services / NFS idmap domain. Должно совпасть с Ubuntu Domain = contoso.example.

5. Логи

Клиент: dmesg | tail, journalctl -u mount. Сервер: /var/log/messages nfsd. Не отключайте firewall навсегда: временно разрешите 2049/tcp (и rpc для v3) на storage NIC.

Решение

Сценарий A. access denied

Добавьте сеть/IP клиента в share. На классических exports: rw,no_subtree_check по политике. Не * на 0.0.0.0/0 в проде.

Проверьте, что экспортируете именно dataset, который смонтирован.

Сценарий B. Timeout

Сеть NAS. На SCALE: NFS service running. Для v3 в TrueNAS включите NFSv3, если клиент старый. Закрепите mountd порт в настройках NFS и откройте его на firewall — иначе showmount жив из подсети NAS и мёртв из офиса.

Сценарий C. Protocol not supported

Клиент vers=4.2 vs сервер max 4.1 — опустите. Или наоборот включите NFSv4 в GUI.

Сценарий D. nobody:nogroup

Выровняйте Domain, перезапустите idmapd на клиенте и смысл на сервере. Для маленьких стендов иногда NFSv3 без idmap проще (UID как есть). Тогда UID пользователя на app01 = UID на NAS01.

Сценарий E. Путь есть в UI, mount No such file

Пул не смонтирован: NAS не видит том. Не создавайте пустой каталог /mnt/tank/share на boot-пуле поверх — замаскируете проблему.

На NFSv4 путь в mount — не всегда тот же, что в showmount. Часто это /share относительно корня экспорта, а не /mnt/tank/share. Сверьте «TrueNAS path» и «NFS mount path» в UI. Ошибка No such file при живом export — почти всегда этот сдвиг, не «пропал tank».

Для idmap на Ubuntu 22.04/24.04 сервис nfs-idmapd, файл /etc/idmapd.conf, после правки Domain — restart idmapd и перемонтирование. Кэш nobody живёт в сессии: umount обязателен. Не чините nobody через chown -R на NAS: вы запишете числовые UID в данные.

Firewall между офисом и storage VLAN: stateful timeout длинных mount (autofs) даёт «иногда отваливается». Держите NFS TCP, hard без короткого intr на проде учёта, и не NAT'ьте NFS, если можете дать прямой маршрут до 10.0.30.10.

Как проверить, что проблема устранена

mount | grep nfs
touch /mnt/nfs/.write-test
ls -l /mnt/nfs/.write-test

Файл виден на NAS01 в /mnt/tank/share с ожидаемым uid. fstab/autofs переживает ребут app01. showmount или nfsstat -m стабильны.

Если не помогло

  • Kerberos NFS: keytab, время, sec=krb5p — отдельный слой, сначала sys в лабе.
  • Один клиент ок, другой denied: разные source IP (NAT).
  • Работает после reboot NAS, потом нет: bind nfsd, middleware.
  • Proxmox storage NFS — те же export, плюс версия в storage.cfg.

Профилактика

  • Явные vers= в fstab.
  • Один NFS domain в организации.
  • Мониторинг exportfs и порта 2049.
  • Не экспортировать корень tank, только нужный dataset.
  • Документировать Maproot vs squash.
  • Сеть storage отдельно от гостевой.

FAQ

Нужен ли no_root_squash для backup?

Иногда для чтения всех файлов от root. Ограничьте IP backup-хоста, не всего офиса.

Почему Windows mount -o anon работает, Ubuntu нет?

Разные клиенты и sec. Не копируйте опции Windows NFS в Linux mount.

Можно ли NFS и SMB на одном dataset?

Да, на TrueNAS часто. Тогда не чините NFS правами NTFS-мышления. Смотрите ACL режима (NFSv4 ACL vs POSIX).

Stale после снапшота?

Сменили fsid/export path. Перемонтируйте. Не reboot всех клиентов пачкой без umount.

2049 открыт, rpcinfo пустой?

Фильтр UDP/TCP rpcbind. Для v4 tcp 2049 часто достаточно; для v3 — нет.