Вопрос или проблема
Я использую NFS между несколькими машинами Debian 10 в своей локальной сети, с одинаковыми базовыми настройками на всех компьютерах, и они все работают, как и ожидалось.
Я использую autofs от имени root для монтирования и размонтирования NFS общего доступа на каждой машине, также используя одинаковые базовые настройки везде. Пользователи на каждой клиентской машине могут получить доступ к смонтированным ресурсам, так как они принадлежат nobody:nogroup.
До сих пор я всегда монтировал ресурсы с сервера на клиентскую машину без проблем. Итак, это две отдельные машины.
Я теперь пытаюсь смонтировать общий доступ, предоставленный с одной машины, используя autofs на той же машине. То есть сервер и клиент на одной машине.
Autofs монтирует общий доступ без проблем, и пользователи, не являющиеся root, могут перечислять содержимое папок и просматривать файлы без проблем, но когда пользователи, не являющиеся root, пытаются записать что-либо в общий доступ, они получают сообщение “permission denied”:
$ touch test.file
touch: невозможно создать 'test.file': Доступ запрещён
$ echo "content" > test.file
bash: test.file: Доступ запрещён
Это происходит как при использовании 127.0.0.1 на локальном соединении, так и при использовании 192.168.x.y на интерфейсе Ethernet или Wi-Fi для доступа к шару. Другие машины используют autofs для монтирования тех же ресурсов с теми же настройками без проблем, и эта машина аналогично использует autofs для монтирования ресурсов с других машин с теми же настройками, опять же без проблем.
Это настройки NFS-сервера:
$ sudo exportfs -v
/exports/share 127.0.0.1/32(rw,wdelay,root_squash,all_squash,sec=sys,rw,secure,root_squash,all_squash)
/exports/share 192.168.0.0/16(rw,wdelay,root_squash,all_squash,sec=sys,rw,secure,root_squash,all_squash)
Это настройки autofs, которые загружаются через основной файл в другом файле:
$ cat /etc/auto.shares
share_loopback -fstype=nfs4,rw,retry=0,hard,noac,noexec,proto=tcp 127.0.0.1:/exports/share
share_network -fstype=nfs4,rw,retry=0,hard,noac,noexec,proto=tcp 192.168.x.y:/exports/share
Когда пользователь вручную монтирует тот же NFS общий доступ на той же машине с теми же базовыми настройками, всё работает нормально, без проблем с правами доступа.
$ sudo mount -t nfs4 -o rw,hard,noac,noexec,proto=tcp 127.0.0.1:/exports/share /media/share_loopback
$ sudo mount -t nfs4 -o rw,hard,noac,noexec,proto=tcp 192.168.x.y:/exports/share /media/share_network
Кажется, что autofs “под капотом” делает что-то иначе, чем когда я монтирую вручную.
Так в чем же причина того, что монтирование через autofs сообщает “Permission denied”, и как я могу заставить это работать?
Ответ или решение
Решение проблемы с NFS и автозапуском (autofs) на одном и том же компьютере
Ваша ситуация с NFS (сеть файловой системы) и autofs, где ваше приложение с NFS для локального компьютера дает сообщение "Permission denied" при попытке записи, имеет несколько возможных причин. Давайте подробно рассмотрим ваше окружение и возможные решения.
Описание проблемы
- Контекст системы: Вы работаете в среде Debian 10, где у вас настраивается NFS-сервер и клиент на одном и том же компьютере.
- Настройки NFS: Вы успешно используете nfs для подключения между несколькими компьютерами, и все параметры настроены одинаково.
- Autofs: Используется для автоматического монтирования экспортов NFS. Однако, при попытке записи в смонтированное пространство, пользователи получают ошибку доступа.
- Ручное монтирование: Ручное монтирование NFS-экспортов успешное, что подтверждает правильность конфигурации сервера.
Причины проблемы
Проблема "Permission denied" указывает на то, что права доступа к файловой системе настроены некорректно в контексте, в котором работает autofs. Ниже приведены возможные причины:
-
Параметры экспорта NFS: Вы используете параметры
root_squashиall_squash, что означает, что все пользователи, включая root, обращаются к экспортируемым ресурсам под UID/GID 65534 (пользовательnobody). Это может быть причиной проблем с правами доступа в NFS-шаре при автоматическом монтировании. -
Контекст монтирования: Autofs может не передавать тот же контекст безопасности в NFS-шар, что приводит к проблемам с правами доступа. По умолчанию, при монтировании через autofs создается временная папка, которая может иметь другие настройки прав.
-
Режимы NFS: Разные версии протокола NFS могут обрабатывать права по-разному. Проверьте, какие именно версии используются и установите их в файл конфигурации.
Рекомендации по решению
-
Изменение параметров экспорта: Попробуйте временно удалить
root_squashиall_squashиз экспортов NFS:/exports/share 127.0.0.1/32(rw,no_root_squash) /exports/share 192.168.0.0/16(rw,no_root_squash)После изменения убедитесь, что вы перезапустили сервис NFS для применения изменений:
sudo exportfs -ra -
Использование правильных UID/GID: Убедитесь, что UID и GID пользователя, который пытается записать файлы на NFS-шаре, совпадают с UID и GID на NFS-сервере. Например, проверьте, как указываются пользователи в autofs и как они отображаются в правилах на сервере.
-
Обновление конфигурации autofs: Проверьте, что конфигурация настроена корректно в соответствии с документацией и, при необходимости, добавьте дополнительные опции при монтировании:
share_loopback -fstype=nfs4,rw,soft,insecure,noauto 127.0.0.1:/exports/share share_network -fstype=nfs4,rw,soft,insecure,noauto 192.168.x.y:/exports/share -
Логирование и диагностика: Настройте уровень логирования NFS и проверьте системные журналы на наличие ошибок в
/var/log/syslogили/var/log/messagesдля дальнейшей диагностики проблемы.
Заключение
Проблема с "Permission denied" при использовании autofs для монтирования NFS-шар на одном и том же компьютере может быть связана с неправильными параметрами экспорта и контекстом монтирования. Попробуйте предложенные выше решения, изменив параметры экспорта и убедившись, что права доступа корректно настроены, а также синхронизировав UID/GID между клиентом и сервером. Проведите тестирование после внесения изменений, чтобы гарантировать, что все будет работать как ожидается.