Debian/Ubuntu: как исправить NFS mount.nfs: access denied by server while mounting

Ошибка mount.nfs: access denied by server while mounting в Debian и Ubuntu почти всегда выглядит обманчиво: кажется, что сломан клиент, хотя на деле сервер просто отвергает запрос на монтирование. Обычно это происходит из-за неправильной записи в /etc/exports, несовпадения IP-адреса клиента с разрешённой сетью, ошибки в пути, различий между NFSv3 и NFSv4 или сетевой фильтрации.

Характерная особенность в том, что базовая связность при этом может быть полностью рабочей. Сервер пингуется, по SSH вы на него заходите, DNS работает, но mount всё равно получает отказ. Поэтому самый полезный подход здесь — не перебирать случайные опции, а пройтись по проверкам в правильном порядке.

В статье разберём диагностику для Debian и Ubuntu на примере: NFS-сервер 192.168.1.10, клиент 192.168.1.20, экспортируемый каталог /srv/nfs/share, точка монтирования на клиенте — /mnt/share.

Сразу держите в голове важную мысль: access denied — это не таймаут и не обрыв сети. Это явный отказ сервера на этапе проверки доступа к экспорту. Значит, искать причину нужно в правилах экспорта, адресации, версии протокола и firewall.

Как выглядит ошибка и что она обычно означает

Типичный пример:

sudo mount -t nfs 192.168.1.10:/srv/nfs/share /mnt/share
mount.nfs: access denied by server while mounting 192.168.1.10:/srv/nfs/share

Та же ошибка может появляться и при монтировании через /etc/fstab, и при явном указании версии протокола. На практике чаще всего причина одна из следующих:

• в /etc/exports указан не тот путь;
• клиентский IP не попадает под разрешённое правило;
• экспорты изменили, но не применили;
• сервер отдаёт один каталог, а клиент монтирует другой;
• в NFSv4 перепутан реальный путь и путь относительно псевдокорня;
• мешает firewall или RPC-сервисы;
• ошибочно подозревается root_squash, хотя проблема не в нём.

Наибольшее количество времени обычно съедают две вещи: неправильная запись в exports и неправильный путь при монтировании. С них и нужно начинать.

Проверяем сервер: работает ли NFS и что он реально экспортирует

На сервере сначала убедитесь, что пакет и служба NFS действительно установлены и запущены. Для Debian и Ubuntu это обычно nfs-kernel-server.

dpkg -l | grep nfs-kernel-server
systemctl status nfs-kernel-server
systemctl status rpcbind

Если сервис не установлен или не поднят, клиентские ошибки могут быть разными, в том числе похожими на отказ доступа. Следующий обязательный шаг — посмотреть содержимое /etc/exports.

cat /etc/exports

Корректная минимальная запись может выглядеть так:

/srv/nfs/share 192.168.1.20(rw,sync,no_subtree_check)

Или так, если доступ нужен всей подсети:

/srv/nfs/share 192.168.1.0/24(rw,sync,no_subtree_check)

После любых изменений файл недостаточно просто сохранить. Экспорты нужно перечитать:

sudo exportfs -ra
sudo exportfs -v

Команда exportfs -v особенно полезна, потому что показывает, как сервер фактически интерпретировал конфигурацию. Это помогает быстро заметить, что вы ожидали одно, а опубликовано другое.

Если вы поменяли /etc/exports, но не выполнили exportfs -ra, сервер продолжит работать со старой конфигурацией, и клиент будет получать тот же отказ.

Частая ошибка: экспортируется один путь, а монтируется другой

Если на сервере экспортирован каталог /srv/nfs/share, а на клиенте вы пытаетесь смонтировать /srv/nfs или просто /share в контексте NFSv3, это уже другой ресурс. Для NFS такие мелочи принципиальны: путь должен соответствовать именно тому, что опубликовано сервером.

Проверьте, что сервер реально отдаёт:

sudo exportfs -v
showmount -e 192.168.1.10

Если нужного каталога нет в списке, почти наверняка проблема на стороне сервера, а не клиента.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Проверяем exports: IP клиента, подсети и правила доступа

Файл /etc/exports очень чувствителен к деталям. Ошибка в адресе, маске или имени хоста легко приводит к полному отказу. Особенно часто это встречается на серверах с несколькими интерфейсами, VLAN, VPN, контейнерными сетями и NAT.

На клиенте проверьте, какой адрес используется реально:

ip a
ip route get 192.168.1.10

Если сервер ожидает трафик от 192.168.1.20, а фактически видит клиент с другого адреса, правило не совпадёт. Это типичный случай в виртуальной инфраструктуре и в сложных сетях. В похожих сценариях полезно также понимать, как работает фильтрация трафика на хосте и в контейнерах — для этого может пригодиться разбор про настройку firewall Docker с iptables и nftables.

Примеры допустимых правил:

/srv/nfs/share 192.168.1.20(rw,sync,no_subtree_check)
/srv/nfs/share 192.168.1.0/24(rw,sync,no_subtree_check)
/srv/nfs/share localhost(rw,sync,no_subtree_check)

На практике для продакшена я советую использовать явные IP или чёткие подсети, а не имена хостов. С ними меньше сюрпризов из-за DNS и обратного резолва.

Быстрая проверка: временно разрешите один IP

Если неясно, проблема в сети или в самом экспорте, временно сузьте правило до одного конкретного клиента:

/srv/nfs/share 192.168.1.20(rw,sync,no_subtree_check)

Затем примените конфигурацию:

sudo exportfs -ra
sudo exportfs -v

Если после этого монтирование заработало, причина почти наверняка в маске сети, маршрутизации или неожиданном исходящем адресе клиента.

Что показывает showmount и как его правильно использовать

showmount — один из самых полезных инструментов в диагностике этой ошибки. На клиенте при необходимости установите пакет:

sudo apt update
sudo apt install -y nfs-common

После этого запросите список экспортов:

showmount -e 192.168.1.10

Ожидаемый вывод будет примерно таким:

Export list for 192.168.1.10:
/srv/nfs/share 192.168.1.0/24

Если showmount видит нужный экспорт, но mount всё равно получает access denied, значит дальше нужно разбираться с путём, версией NFS или параметрами экспорта. Если же список пуст или команда не возвращает нужный каталог, обычно виноват один из трёх факторов:

• экспорт не опубликован или не перечитан;
• доступ блокирует firewall;
• RPC-сервисы не работают или недоступны.

Важно помнить, что showmount исторически лучше отражает картину для NFSv3. В сценариях, ориентированных только на NFSv4, он не всегда показывает всё идеально, но как быстрый тест всё равно очень полезен.

NFSv4: когда проблема в неправильном пути монтирования

Это одна из самых неприятных ловушек. В NFSv4 клиент нередко должен монтировать не физический путь на диске, а путь относительно псевдокорня сервера. Из-за этого конфигурация может выглядеть правильной, а mount при этом получать отказ.

Пример серверной конфигурации:

/srv/nfs 192.168.1.0/24(ro,fsid=0,sync,no_subtree_check)
/srv/nfs/share 192.168.1.0/24(rw,sync,no_subtree_check)

В таком случае для NFSv4 клиент часто должен использовать путь не 192.168.1.10:/srv/nfs/share, а путь относительно fsid=0:

sudo mount -t nfs4 192.168.1.10:/share /mnt/share

Если же монтировать физический путь с диска, вы легко получите тот же access denied by server while mounting, хотя сами экспорты формально существуют.

Для диагностики удобно явно проверить обе версии протокола:

sudo mount -t nfs -o vers=3 192.168.1.10:/srv/nfs/share /mnt/share
sudo mount -t nfs -o vers=4 192.168.1.10:/share /mnt/share

Такой тест быстро показывает, где именно расхождение: в публикации каталога или в модели путей NFSv4.

root_squash, no_root_squash и частая путаница при диагностике

Параметр root_squash часто вспоминают первым, но обычно он не является причиной самой ошибки монтирования. Его задача — ограничить root-пользователя клиента, сопоставив его с непривилегированным пользователем на сервере. Из-за этого чаще ломаются операции записи, смены владельца и прав уже после успешного mount.

Путаница возникает потому, что сначала администратор замечает странные права внутри смонтированного каталога, потом меняет параметры экспорта, затем случайно ломает правило в exports — и в итоге получает уже полноценный access denied. Кажется, будто виноват root_squash, хотя проблема появилась в другом месте.

Посмотреть фактические параметры экспорта можно так:

sudo exportfs -v

Для большинства сценариев root_squash — безопасное значение по умолчанию. Менять его на no_root_squash стоит только при полном понимании последствий и доверии к клиенту.

Если mount завершается ошибкой access denied, сначала проверяйте экспорт, путь, IP клиента и версию NFS. root_squash обычно проявляет себя уже после успешного монтирования.

Зачем добавляют no_subtree_check

no_subtree_check редко бывает единственной причиной ошибки, но он делает поведение экспорта более предсказуемым, особенно если вы отдаёте не корень файловой системы, а вложенный каталог. Поэтому в практических конфигурациях его обычно ставят вместе с rw и sync.

Минимальный шаблон выглядит так:

/srv/nfs/share 192.168.1.0/24(rw,sync,no_subtree_check)

Если у вас наблюдаются странности при переносах, переименованиях или экспорте вложенных каталогов, этот параметр помогает убрать лишнюю неопределённость. Он не чинит всё подряд, но делает конфигурацию стабильнее.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Firewall NFS: как проверить, что блокировка именно в сети

Ещё одна типичная причина — firewall. Особенно часто это забывают проверить, когда SSH на сервер доступен, а порты NFS и RPC отфильтрованы. Тогда часть команд может работать, а часть — нет, и картина выглядит противоречиво.

На сервере проверьте, слушаются ли нужные порты и сервисы:

ss -tulpn | grep -E '2049|111'
rpcinfo -p 192.168.1.10

Затем посмотрите правила фильтрации:

sudo nft list ruleset
sudo ufw status verbose

Для базовой диагностики обычно важны:

• порт 2049 для NFS;
• порт 111 для rpcbind, если он используется;
• дополнительные RPC-сервисы в сценариях с NFSv3.

Если у вас сложная схема маршрутизации, несколько адресов или NAT, полезно отдельно проверить правила трансляции и исходящий адрес, под которым клиент приходит на сервер. В таких случаях может пригодиться материал про управление SNAT в nftables при нескольких IP.

Проверяйте сеть по шагам: сначала доступность сервиса, потом showmount, потом уже монтирование. Это быстрее, чем отключать защиту наугад.

Права на каталог и состояние файловой системы на сервере

Хотя сообщение об ошибке относится к доступу на этапе монтирования, базовую проверку самого каталога тоже делать нужно. Если путь не существует, расположен на не смонтированном томе или вы экспортируете не тот каталог, диагностика начинает путаться.

ls -ld /srv/nfs /srv/nfs/share
stat /srv/nfs/share
mount | grep /srv/nfs/share

Убедитесь, что каталог действительно существует и что сервер экспортирует именно его. Частый случай — каталог указан в конфиге, но лежит на отдельном разделе, который после перезагрузки не смонтировался.

Какие логи смотреть в Debian и Ubuntu

Когда команда mount уже дала отказ, самый быстрый путь к причине — сразу открыть журналы на сервере и клиенте. Часто там есть прямое указание, какой IP отклонён или какой экспорт не найден.

На сервере:

sudo journalctl -u nfs-kernel-server -n 100 --no-pager
sudo journalctl -u rpcbind -n 100 --no-pager
sudo dmesg | tail -n 50

На клиенте:

sudo journalctl -n 100 --no-pager
sudo dmesg | tail -n 50

Это почти всегда полезнее, чем повторять одну и ту же команду монтирования без изменения условий.

Рабочий чек-лист: что делать по порядку

Если нужно быстро вернуть сервис в строй, используйте такой порядок:

1. На сервере проверьте, что установлены и запущены nfs-kernel-server и при необходимости rpcbind.
2. Убедитесь, что экспортируемый каталог реально существует.
3. Проверьте /etc/exports и временно разрешите доступ одному конкретному IP клиента.
4. Примените конфигурацию через exportfs -ra.
5. Посмотрите итог через exportfs -v.
6. С клиента выполните showmount -e.
7. Проверьте, тот ли путь вы монтируете для NFSv3 или NFSv4.
8. Проверьте firewall и доступность портов 2049 и 111.
9. Сразу после неудачи откройте журналы на сервере и клиенте.

Такой порядок отсекает наиболее вероятные причины без лишних действий.

Пример минимально корректной конфигурации

Для простой локальной сети можно начать с такого минимального варианта.

На сервере:

sudo apt update
sudo apt install -y nfs-kernel-server
sudo mkdir -p /srv/nfs/share
sudo chown nobody:nogroup /srv/nfs/share
sudo chmod 0775 /srv/nfs/share

Файл /etc/exports:

/srv/nfs/share 192.168.1.20(rw,sync,no_subtree_check)

Применение:

sudo exportfs -ra
sudo exportfs -v
systemctl restart nfs-kernel-server

На клиенте:

sudo apt update
sudo apt install -y nfs-common
sudo mkdir -p /mnt/share
showmount -e 192.168.1.10
sudo mount -t nfs 192.168.1.10:/srv/nfs/share /mnt/share

Если этот пример работает, а ваша реальная конфигурация — нет, значит проблема находится в дополнительных ограничениях: версии протокола, путях, сети, именах хостов или правилах firewall.

Когда проблема не в клиенте, а в самой схеме доступа

В окружениях с NAT, VPN, гипервизорами, контейнерными сетями и облачными ACL ошибка нередко связана не с NFS как таковым, а с тем, что сервер видит клиента не с того адреса, который вы ожидаете. Для тестовых стендов, CI, файловых сервисов и внутренней инфраструктуры такие кейсы проще разбирать на отдельном сервере с полностью контролируемой сетью. В этом сценарии удобно использовать VDS, где вы управляете маршрутизацией, nftables, ufw и самим стеком Debian или Ubuntu без ограничений платформы.

Итог

Если коротко, mount.nfs: access denied by server while mounting в Debian и Ubuntu почти всегда сводится к одной из пяти причин: неверный экспорт в /etc/exports, неподходящий IP клиента, неправильный путь монтирования, различия между NFSv3 и NFSv4 или блокировка firewall.

Самая надёжная стратегия — не угадывать, а подтверждать гипотезы командами: exportfs -v, showmount -e, rpcinfo -p, просмотром журналов и явным указанием версии протокола. Такой подход обычно экономит много времени и быстро показывает реальное расхождение между ожидаемой и фактической конфигурацией.