Вопрос или проблема
Я сталкиваюсь с очень странной проблемой при монтировании NFS-ресурса через systemd mount.
Для сервера NFS я использую TrueNAS. На TrueNAS я отключил версию NFS 3 и включил только версию 4.
Проблема в том, что когда я пытаюсь запустить службу монтирования systemd, она всегда терпит неудачу, если я не включу поддержку NFS версии 3 на TrueNAS. Мой файл монтирования systemd выглядит следующим образом:
[Unit]
Description=Mount the NFS share for MinIO object storage
After=network.target
[Mount]
What=10.0.0.1:/mnt/data-dock/MinIO-Storage/Production
Where=/mnt/data
Type=nfs
Options=_netdev,auto,vers=4.1
[Install]
WantedBy=multi-user.target
Однако при выполнении напрямую через командную строку с командой ниже все работает с версией NFS 4:
sudo mount -t nfs 10.0.0.1:/mnt/data-dock/MinIO-Storage/Production /mnt/data -o defaults,hard,intr,proto=tcp,vers=4.1,_netdev,auto
Логи дают мне немного больше информации:
mount.nfs: access denied by server while mounting 10.0.0.1:/mnt/data-dock/MinIO-Storage/Production
Из этого я заключаю, что systemd mount по какой-то причине возвращается к версии 3 и поэтому получает отказ в доступе, но не может подключиться, так как версия NFS 3 отключена, даже несмотря на то, что в моем конфигурационном файле systemd я указываю использовать версию 4.
Я пробовал это с Ubuntu, Rocky Linux 9, Debian Bookworm, и у всех одинаковая проблема. Я делаю что-то неправильно или это баг в systemd mount?
Благодарю и с уважением
Ответ или решение
При решении проблем с монтированием NFS-ресурсов средствами systemd, особенно если речь идет об использовании протокола NFS версии 4, важно учитывать различные аспекты, влияющие на поведение системы. В описанном вами сценарии вы столкнулись с ситуацией, когда systemd пытается использовать NFS версии 3, несмотря на то, что в конфигурации указана версия 4.1. Давайте подробно рассмотрим возможные причины и пути решения этой проблемы.
Теория
Протокол NFS (Network File System) позволяет клиентам получить доступ к удаленным файловым системам через сеть. NFS версии 4 предлагает улучшенные возможности: встроенные функции безопасности, единую операционную среду для всех клиентов и серверов и множество улучшений в производительности. Однако, одна из особенностей NFSv4 заключается в том, что он больше полагается на правильную настройку взаимодействия сервер-клиент, включая аутентификацию и авторизацию через механизмы безопасности, такие как Kerberos.
Пример
Ваш файл монтирования через systemd имеет следующий вид:
[Unit]
Description=Mount the NFS share for MinIO object storage
After=network.target
[Mount]
What=10.0.0.1:/mnt/data-dock/MinIO-Storage/Production
Where=/mnt/data
Type=nfs
Options=_netdev,auto,vers=4.1
[Install]
WantedBy=multi-user.targetВы указываете использование NFS версии 4.1, что должно исключать использование NFSv3. Однако система возвращает ошибку "доступ запрещен", что говорит о возможной проблеме с аутентификацией или неверной настройкой клиента или сервера.
Применение
Проверьте разрешения
Убедитесь, что указанный в конфигурации путь на сервере (то есть 10.0.0.1:/mnt/data-dock/MinIO-Storage/Production) настроен таким образом, что клиент имеет разрешение на подключение. Имейте в виду, что NFSv4 использует концепцию root squash, что может влиять на разрешения учетной записи клиента.
Настройки безопасности
Убедитесь, что настройки безопасности (например, использование Kerberos) на сервере и клиенте согласованы. Если ваш сервер ожидает, что клиент будет использовать определенные механизмы безопасности, либо обеспечьте их соответствие, либо настройте сервер для поддержки более простых методов аутентификации.
Журналирование и дебаггинг
Проанализируйте логи более глубоко. Используя команду journalctl, проверьте, нет ли дополнительных ошибок или предупреждений, связанных с systemd или NFS:
journalctl -xeЭто может дать дополнительные указания на возможные причины, прячущиеся под поверхностью проблемы.
Сравните версии mount
Проверьте, какие версии mount и nfs-utils используются на вашей системе. Старые версии могут иметь баги или несовместимости, касающиеся обработки иных параметров, чем те, что указаны в командной строке, когда выполняется ручное монтирование. Попробуйте обновить пакеты, если они не актуальны.
Идентификация службы
Система systemd предоставляет гибкость, но также есть вероятности нюансов из-за порядка запуска сервисов и опций. Попробуйте добавить зависимости в ваш unit-файл, чтобы убедиться, что все необходимое для корректного подключения работает к тому моменту, когда производится монтирование:
[Unit]
Requires=network-online.target
After=network-online.targetЭти изменения помогут убедиться, что сеть полностью инициализирована перед монтированием.
Тестирование альтернативных сценариев
Создайте временный тестовый сервисный файл с вызовом mount через ExecStart и проверьте, как он себя ведет:
[Unit]
Description=Temporary NFS Mount
After=network.target
[Service]
Type=oneshot
ExecStart=/bin/mount -t nfs -o vers=4.1 10.0.0.1:/mnt/data-dock/MinIO-Storage/Production /mnt/data
RemainAfterExit=yes
[Install]
WantedBy=multi-user.targetЕсли этот способ срабатывает, проблема может заключаться в самой монтировании через unit-type Mount.
Завершение
Если предложенные шаги не решают проблему, рассмотрите возможность создании проблемы на платформе для отслеживания ошибок используемой операционной системы или в хранилище systemd. Будет полезно предоставить как можно больше информации: все журналы, используемые версии, конфигурации и любые другие наблюдения. Это может ускорить процесс выявления и исправления возможной ошибки.
Резюмируя, проблема с монтированием NFS через systemd зачастую связана с несовпадением конфигураций или особенностями работы сетеых сервисов в момент их инициализации. Комплексный подход к диагностике, включающий проверку всей цепочки — от конфигураций до версии используемого программного обеспечения, — обеспечит понимание и решение вашей проблемы.