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

Пока NFS красный, не удаляйте storage из PVE и не переименовывайте шару на NAS «для чистоты». Проверьте сеть до сервера (плейсхолдер 10.0.10.20), showmount -e, версию nfsvers, опции export (root squash) и для v4 — idmapd. Образы на шаре обычно целы; PVE лишь не может смонтировать path из storage.cfg.

С pve1 должен отвечать RPC/NFS, не только ICMP.

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

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

  • pvesm status для NFS inactive / error;
  • mount без привычной точки /mnt/pve/<id>;
  • задачи backup: cannot write / timeout;
  • в dmesg: NFS: server 10.0.10.20 not responding, stale file handle.

Отличия:

Что видноНе NFS как протоколКуда смотреть
Все storage мертвыpmxcfsХранилище недоступно
iSCSI красный, NFS зелёныйдругая SANiSCSI
NFS зелёный, VM без сетиguest NICСеть VM
Backup падает при живом mountlock/местоvzdump

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

  1. NAS выключен, VLAN, ACL, firewall на 111/2049.
  2. Export не отдаёт сеть pve1 (10.0.10.11) или отдаёт только v4, а в PVE прописан v3.
  3. После ребута NAS изменился FSID — stale handle, нужен umount/mount.
  4. root_squash: PVE пишет как root, получает Permission denied.
  5. idmap NFSv4: nobody/nogroup, файлы «не те».
  6. MTU/jumbo между vmbr0 management и NAS, обрыв больших WRITE.

Диагностика

На pve1 (подставьте IP NAS 10.0.10.20 и имя storage из cfg):

pveversion
pvesm status
grep -A8 -E '^nfs:|^dir:' /etc/pve/storage.cfg
ip -br addr

Сеть и RPC:

ping -c 3 10.0.10.20
rpcinfo -p 10.0.10.20
showmount -e 10.0.10.20

showmount требует v3 mountd. Если NAS только v4, showmount может быть пустым при живом NFS — тогда mount -t nfs4.

Проверка порта:

nc -vz 10.0.10.20 2049
nc -vz 10.0.10.20 111

Журнал:

journalctl -k -b --no-pager | grep -i nfs | tail
dmesg | grep -i stale

Решение

Сценарий A. Сеть/firewall

Откройте на NAS и промежуточных ACL нужные порты NFS для management-сети узлов. Не отключайте pve-firewall навсегда: добавьте правило к 10.0.10.20. Если management сидит не на vmbr0, чините маршруты, см. bridge.

Сценарий B. Export не включает pve1

На NAS добавьте 10.0.10.11 (и всех членов кластера) в export. Для PVE часто нужен no_root_squash на datastore образов — иначе qemu не создаст диск. Это сознательная уступка безопасности: шара не должна торчать в пользовательские VLAN.

После правки:

showmount -e 10.0.10.20
pvesm status

PVE сам монтирует в /mnt/pve/<storage-id>.

Сценарий C. Версия NFS

В GUI storage: NFS version. Несовпадение v3/v4 даёт timeout. Зафиксируйте ту версию, которую NAS реально отдаёт. Для v4 проверьте /etc/idmapd.conf Domain на узле и NAS.

Сценарий D. Stale file handle

umount -f /mnt/pve/nfs-backup
# затем дождитесь, пока pvestatd снова смонтирует, или
pvesm status

Не umount -l как первую мысль на шаре, куда сейчас пишет vzdump: сначала остановите backup.

Сценарий E. Permission denied / nobody

root squash или idmap. Файлы от nobody не «чините» chown -R root по всей шаре с другого клиента, пока не поняли squashing — затрёте чужие UID.

Монтирование глазами pvestatd и опции rsize/wsize

PVE монтирует NFS сам через pvestatd. Ручной mount в тот же path конфликтует, если опции другие. Смотрите фактические флаги:

findmnt /mnt/pve
grep nfs /proc/mounts
systemctl status pvestatd --no-pager

Для диагностики допустим временный mount -t nfs -o vers=4.2,soft в другой каталог (/mnt/nfs-test), не в /mnt/pve/<id>. Там проверьте ls и запись тестового файла. Затем umount теста. Не оставляйте soft на боевом qcow.

nconnect, rsize/wsize крутите только после доказательства мелкого MSS/MTU, не «с форума 1M». Jumbo 9000 на pve1 и 1500 на NAS даёт скрытые обрывы крупных WRITE — это выглядит как offline storage. Сверьте MTU на management и на интерфейсе NAS 10.0.10.20.

Экспорт с all_squash ломает создание образов qemu. anonuid без согласования с uid root на PVE — тот же класс. Фиксируйте опции export в заявке, не только IP.

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

pvesm status
mount | grep /mnt/pve
ls /mnt/pve/<id>
qm status 101

Storage active. Каталог показывает те же vzdump-qemu-101-* / qcow, что до сбоя. Тестовая запись: маленький файл в шаре от root на pve1, затем удалить. Старт VM, чей диск на NFS, либо тестовый vzdump на этот storage.

С pve2 (если кластер) — тот же pvesm status: иначе миграция на NFS сломается.

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

  • ICMP есть, 2049 нет: фильтр, NFS не слушает на этом IP NAS (bind).
  • Только один узел: его IP не в export, или свой firewall.
  • После смены IP NAS обновите server в storage cfg, не создавайте второй NFS на тот же path.
  • Высокий IO, storage «мигает»: IO wait, канал 1 Гбит vs много qcow.
  • Kerberos NFS (sec=krb5): сначала время и keytab, не sec=sys «навсегда» в проде без решения.

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

  • Export явно по узлам кластера, не *.
  • Мониторинг mount и 2049 с каждого PVE.
  • Jumbo MTU симметрично или нигде.
  • Backup VM не только на тот же NAS, что и рабочие qcow.
  • Документировать nfsvers и squash.

FAQ

PVE использует NFSv3 или v4 по умолчанию?

Зависит от того, что выбрали при создании storage и что отдаёт сервер. Смотрите mount опции vers=.

Нужен ли no_root_squash всегда?

Для datastore с образами qemu — обычно да. Для архива, куда пишет непривилегированный клиент — нет.

Можно ли держать /etc/pve на NFS?

Нет. pmxcfs — отдельная fuse-ФС кластера. NFS только как storage содержимого VM/ISO/backup.

showmount пустой, GUI зелёный — это норма?

Возможно только NFSv4 без mountd. Тогда ориентир — rpcinfo и mount.

Стоит ли hard vs soft mount?

PVE монтирует сам. Не переводите на soft, чтобы «GUI ожил»: получите порчу qcow при обрыве. Чините сеть.