Ошибка mount.nfs: No such device появляется при попытке смонтировать NFS-шару командой mount -t nfs и почти всегда означает, что система не может найти поддержку NFS на уровне ядра или пользовательских утилит — сетевая доступность сервера здесь ни при чём. Типичный сценарий: после свежей установки минимального образа Debian, Ubuntu или CentOS администратор выполняет mount 192.168.1.10:/share /mnt и получает отказ, хотя сам сервер исправно отдаёт шару другим машинам.
Формулировка «No such device» вводит в заблуждение: она намекает на проблему с устройством, но в контексте NFS речь идёт об отсутствующем модуле ядра, неустановленном пакете nfs-common (или nfs-utils) либо о сбое вспомогательных служб. Ниже разберём, как отличить одну причину от другой и устранить каждую из них без переустановки системы.
Что означает ошибка No such device при монтировании NFS
Когда вы вызываете mount с типом файловой системы nfs, утилита обращается к хелперу /sbin/mount.nfs, а тот — к ядру, запрашивая драйвер NFS-клиента. Если ядро собрано без поддержки NFS, модуль не загружен или сам хелпер отсутствует, система возвращает код ENODEV, который и отображается как «No such device».
Важно отличать эту ошибку от похожих сообщений. Connection timed out говорит о сетевой недоступности сервера, access denied by server — о проблемах с экспортом и правами, а вот No such device — это локальная проблема клиента. Поэтому пинговать сервер и перенастраивать /etc/exports на нём в данном случае бессмысленно: диагностику начинаем с самой клиентской машины.
Проверка установленных пакетов NFS
Самая частая причина — отсутствие пакета с утилитами NFS-клиента. В минимальных и серверных установках дистрибутивов он часто не входит в состав по умолчанию. Проверьте наличие пакета командой, соответствующей вашему дистрибутиву:
# Debian / Ubuntu
dpkg -l | grep nfs-common
RHEL / CentOS / Fedora / Alma / Rocky
rpm -qa | grep nfs-utils
Если пакет не найден, установите его. Для Debian и Ubuntu используется команда apt install nfs-common, для систем семейства Red Hat — dnf install nfs-utils (в старых версиях — yum). После установки попробуйте смонтировать шару повторно — в большинстве подобных случаев проблема решается именно на этом шаге.
Дополнительно убедитесь, что хелпер физически существует: команда ls -l /sbin/mount.nfs должна показать файл. Если пакет установлен, а файла нет, возможно повреждение пакета — переустановите его принудительно.
Проверка модуля ядра NFS
Вторая по частоте причина — незагруженный или отсутствующий модуль ядра. Проверьте, загружен ли он, и попробуйте загрузить вручную:
lsmod | grep nfs
modprobe nfs
modprobe nfsv4
Если modprobe возвращает ошибку вида modprobe: FATAL: Module nfs not found, значит, в текущем ядре поддержки NFS нет. Такое встречается в кастомных ядрах, минимальных сборках для встраиваемых систем и некоторых облачных образах с урезанным ядром. Проверить конфигурацию можно командой grep CONFIG_NFS_FS /boot/config-$(uname -r) — значение m или y означает наличие поддержки.
- 🐧 CONFIG_NFS_FS=m — поддержка есть в виде модуля, достаточно
modprobe nfs. - 🔧 CONFIG_NFS_FS=y — поддержка встроена в ядро, модуль грузить не нужно.
- 🚫 CONFIG_NFS_FS is not set — ядро собрано без NFS, потребуется установить стандартное ядро дистрибутива или пересобрать текущее.
- 📦 В Debian/Ubuntu модуль входит в пакет
linux-image, в RHEL-подобных — в пакетkernel-modules.
⚠️ Внимание: если ошибка появилась сразу после обновления ядра, проверьте, не загрузились ли вы со старой версии, для которой модули уже удалены. Сравните выводuname -rсо списком каталогов в/lib/modules/— при несовпадении перезагрузитесь в актуальное ядро или переустановите пакет ядра.
Особенности работы в контейнерах и chroot
Отдельный класс случаев — попытка смонтировать NFS внутри контейнера Docker, LXC или окружения chroot. Модули ядра здесь общие с хостом, а загружать их из контейнера обычно запрещено политиками безопасности. Результат — тот самый No such device даже при полностью исправной системе.
Порядок действий в такой ситуации: сначала загрузите модуль nfs на хосте командой modprobe nfs, затем запустите контейнер с нужными привилегиями (для Docker это --privileged или как минимум --cap-add SYS_ADMIN). Альтернатива без повышения прав — смонтировать NFS-шару на хосте и пробросить её в контейнер как bind-mount через параметр -v. Второй вариант предпочтительнее с точки зрения безопасности.
Почему chroot тоже выдаёт No such device
В chroot-окружении (например, при восстановлении системы с LiveCD) часто отсутствуют примонтированные /proc, /sys и /dev, а также доступ к модулям ядра. Перед монтированием NFS в chroot выполните: mount --bind /proc /mnt/proc, mount --bind /sys /mnt/sys, mount --bind /dev /mnt/dev. Без этих шагов хелпер mount.nfs не сможет корректно обратиться к ядру.
Пошаговая диагностика: универсальный чек-лист
Чтобы не гадать, пройдите проверки последовательно — от самых простых к более глубоким. Каждый шаг либо решает проблему, либо сужает круг поиска.
☑️ Диагностика mount.nfs
Если все пункты пройдены, а монтирование всё ещё не работает, посмотрите подробный вывод команды с ключом verbose: mount -v -t nfs server:/share /mnt. Дополнительную информацию даст журнал ядра — dmesg | tail сразу после неудачной попытки.
Различия сообщений об ошибках при монтировании NFS
Правильная интерпретация сообщения экономит время: каждая ошибка указывает на свой слой проблемы. Сводная таблица поможет быстро определить направление диагностики.
| Сообщение об ошибке | Уровень проблемы | Первое действие |
|---|---|---|
| No such device | Клиент: модуль ядра или пакеты | modprobe nfs, проверка nfs-common |
| Connection timed out | Сеть или файрвол | Проверить доступность порта 2049 |
| Connection refused | Сервер: NFS-служба не запущена | Проверить nfs-server на стороне сервера |
| access denied by server | Экспорт и права на сервере | Проверить /etc/exports и showmount -e |
| mount.nfs: Operation not permitted | Права пользователя или контейнер | Запуск через sudo, проверка capabilities |
Обратите внимание на последнюю строку таблицы: Operation not permitted легко спутать с No such device, если выполнять монтирование без прав root. Всегда используйте sudo или запись в /etc/fstab с корректными опциями.
Монтирование через /etc/fstab и systemd
Когда ручное монтирование успешно, но после перезагрузки шара не появляется, а в журнале виден тот же No such device, причина обычно в порядке загрузки: systemd пытается смонтировать NFS до поднятия сети и до загрузки модуля ядра. Для сетевых файловых систем в /etc/fstab обязательно указывайте опцию _netdev:
192.168.1.10:/share /mnt/nfs nfs defaults,_netdev 0 0Опция _netdev сообщает системе, что монтирование нужно отложить до готовности сетевой подсистемы. Дополнительно полезны опции x-systemd.automount и noauto — они превращают монтирование в ленивое: шара подключается при первом обращении к каталогу, а не в момент загрузки. Это снижает зависимость от таймингов старта служб.
⚠️ Внимание: после любого редактирования/etc/fstabвыполняйтеsystemctl daemon-reloadи проверяйте конфигурацию командойmount -aдо перезагрузки. Ошибка в fstab может привести к остановке загрузки системы в аварийный режим.
Когда ничего не помогает
Если пакеты установлены, модуль загружается, а ошибка сохраняется, остаются менее типичные сценарии. Проверьте, не используется ли ядро из нестандартного источника — например, некоторые VPS-провайдеры подставляют собственное ядро, где NFS может быть вырезан. В таком случае решение — смена тарифа/образа или использование альтернативы вроде SSHFS.
Также убедитесь, что в системе нет конфликта версий: например, хелпер mount.nfs от старого пакета при обновлённом ядре. Команда mount.nfs -V покажет версию утилиты. Наконец, проверьте целостность файловой системы и наличие свободного места в корневом разделе — при переполненном / установка пакетов и загрузка модулей могут завершаться с ошибками, которые маскируются под другие сбои.
Часто задаваемые вопросы
Почему ошибка No such device появилась после обновления системы?
Наиболее вероятная причина — обновление ядра, после которого система загрузилась с новой версией, а модули для неё установлены не полностью, либо наоборот: загружено старое ядро, модули которого уже удалены. Сравните вывод uname -r с содержимым /lib/modules/ и при несовпадении перезагрузитесь в корректное ядро или переустановите пакет ядра.
Можно ли смонтировать NFS в Docker-контейнере?
Да, но с ограничениями. Модуль ядра nfs должен быть загружен на хосте, а контейнеру нужны привилегии: флаг --cap-add SYS_ADMIN или --privileged. Более безопасная альтернатива — смонтировать шару на хосте и пробросить каталог в контейнер через -v, либо использовать volume-драйвер NFS, если он поддерживается вашей версией Docker.
Чем No such device отличается от No such file or directory при монтировании?
No such file or directory указывает на отсутствие точки монтирования (создайте каталог через mkdir -p /mnt/nfs) или несуществующий путь экспорта на сервере. No such device означает отсутствие поддержки NFS в системе клиента — модуль ядра или пакет утилит. Это принципиально разные уровни проблемы.
Нужен ли перезапуск сервисов после установки nfs-common?
Как правило, нет — для клиентского монтирования достаточно установки пакета и загруженного модуля ядра. Службы вроде rpcbind требуются в основном для NFSv3 с его динамическими портами; для NFSv4 монтирование обычно работает сразу. Если монтирование по NFSv3 не удаётся, проверьте состояние rpcbind командой systemctl status rpcbind.
Как проверить, что шара смонтировалась успешно?
Выполните mount | grep nfs или df -h /mnt/nfs — в выводе должна появиться строка с типом nfs или nfs4 и адресом сервера. Затем проверьте доступность данных: ls /mnt/nfs. Команда findmnt /mnt/nfs дополнительно покажет опции, с которыми выполнено монтирование.