mount.nfs4: доступ отклонен сервером при монтировании (хотя раньше с теми же конфигурациями все работало)

Вопрос или проблема

Пытаюсь примонтировать набор папок nfs на сервер, который был перезапущен, теперь получаю ошибки “доступ запрещен сервером”. На клиентском сервере (clientserver.co.local) я выполнил:

[root@clientserver ~]# mount -t nfs -vvvv 172.18.4.97:/datalake/raw/org /datalake/org/raw/
mount.nfs: timeout set for Wed Dec 30 19:41:35 2020
mount.nfs: trying text-based options 'vers=4.1,addr=172.18.4.97,clientaddr=172.18.4.98'
mount.nfs: mount(2): Permission denied
mount.nfs: trying text-based options 'vers=4.0,addr=172.18.4.97,clientaddr=172.18.4.98'
mount.nfs: mount(2): Permission denied
mount.nfs: trying text-based options 'addr=172.18.4.97'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 172.18.4.97 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 172.18.4.97 prog 100005 vers 3 prot UDP port 20048
mount.nfs: mount(2): Permission denied
mount.nfs: access denied by server while mounting 172.18.4.97:/datalake/raw/org

и получил ошибку, которую видите выше. (Заметьте, он пытается использовать все различные версии nfs и все равно терпит неудачу). Не уверен, какой вариант безопасности использовать (не помню, чтобы я задавал это раньше, и мы используем SSSD для связывания наших Windows AD-аккаунтов с клиентскими и nfs-серверами, так что предполагаю, что это по умолчанию), но в любом случае я пробовал с обоими параметрами -o sec=sys и -o sec=krb5 и получил те же результаты.

Я запускал tcmpdump для мониторинга трафика пакетов во время команды монтирования (основываясь на советах здесь), но не имею понятия, как интерпретировать логи (могу выложить что-то вроде последних 10 строк, если это поможет).

Проверяя монтирования в сети с сервера nfsserver.co.local на клиенте, я увидел:

[root@clientserver ~]# showmount -e
Export list for clientserver.co.local:
[root@clientserver ~]# showmount -e 172.18.4.97
Export list for 172.18.4.97:
/datalake/raw/org/HI_BRFSS               clientserver.co.local,otherclient.co.local
/datalake/raw/org                        clientserver.co.local,otherclient.co.local
/datalake/analytics/org                  clientserver.co.local,otherclient.co.local


[root@clientserver ~]# service nfs status
Redirecting to /bin/systemctl status nfs.service
● nfs-server.service - NFS server and services
   Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; disabled; vendor preset: disabled)
   Active: active (exited) since Wed 2020-12-30 18:32:09 HST; 11min ago
  Process: 93274 ExecStopPost=/usr/sbin/exportfs -f (code=exited, status=0/SUCCESS)
  Process: 93271 ExecStopPost=/usr/sbin/exportfs -au (code=exited, status=0/SUCCESS)
  Process: 93266 ExecStop=/usr/sbin/rpc.nfsd 0 (code=exited, status=0/SUCCESS)
  Process: 93307 ExecStartPost=/bin/sh -c if systemctl -q is-active gssproxy; then systemctl reload gssproxy ; fi (code=exited, status=0/SUCCESS)
  Process: 93290 ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS (code=exited, status=0/SUCCESS)
  Process: 93288 ExecStartPre=/usr/sbin/exportfs -r (code=exited, status=0/SUCCESS)
 Main PID: 93290 (code=exited, status=0/SUCCESS)
    Tasks: 0
   CGroup: /system.slice/nfs-server.service

Dec 30 18:32:09 clientserver.co.local systemd[1]: Starting NFS server and services...
Dec 30 18:32:09 clientserver.co.local systemd[1]: Started NFS server and services.

Так что все выглядит так, как должно бы (showmount действительно показывает папку nfs, которую я пытаюсь примонтировать).

После выполнения команды mount, то, что я вижу в потоке файла /var/log/messages, это просто куча сообщений вроде

Jan  4 18:37:12 clientserver gssproxy: gssproxy[2557]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure.  Minor code may provide more information, Client 'host/[email protected]' not found in Kerberos database

Не уверен, что это значит, но проверил файл gssproxy.conf и он показывает

[root@mclientserver ~]# cat /etc/gssproxy/gssproxy.conf 
[gssproxy]

Не уверен, что это значит тоже, так как не помню, чтобы я когда-либо с этим взаимодействовал в прошлом (когда монтирование nfs все еще работало).

Мы используем SSSD (не настраивал это), чтобы связать наши Windows AD аккаунты с машиной, но я не уверен, может ли это как-то быть связано здесь или это что-то еще. В любом случае, sssd.conf показан ниже

[root@clientserver ~]# cat /etc/sssd/sssd.conf 

[sssd]
domains = co.local
config_file_version = 2
services = nss, pam

[domain/co.local]
ad_domain = co.local
ad_server = adserver.CO.local
ad_backup_server = adserverbackup.CO.local
krb5_realm = CO.LOCAL
realmd_tags = manages-system joined-with-samba 
cache_credentials = False
enumerate = true
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = False
use_fully_qualified_names = False
override_homedir = /home/%u
access_provider = ad

Но кроме этого, ничего в логах, похоже, не дает больше информации, чем та, что я уже видел по ошибке команды…

[root@clientserver ~]# grep mount -rnw /var/log/messages* -e "nfs"
grep: mount: No such file or directory
/var/log/messages:2782:Jan  4 17:21:23 clientserver kernel: FS-Cache: Netfs 'nfs' registered for caching
/var/log/messages:2844:Jan  4 17:21:24 clientserver mount: mount.nfs: access denied by server while mounting nfsserver.co.local:/datalake/analytics/org
/var/log/messages:2845:Jan  4 17:21:24 clientserver mount: mount.nfs: access denied by server while mounting nfsserver.co.local:/datalake/raw/org
/var/log/messages-20201227:3590:Dec 23 17:46:04 clientserver kernel: FS-Cache: Netfs 'nfs' registered for caching
[root@clientserver ~]# 
[root@clientserver ~]# 
[root@clientserver ~]# 
[root@clientserver ~]# grep mount -rnw /var/log/messages* -e "mount"
grep: mount: No such file or directory
/var/log/messages:2380:Jan  4 17:20:55 clientserver kernel: XFS (dm-3): Ending clean mount
/var/log/messages:2530:Jan  4 17:21:07 clientserver kernel: XFS (sda1): Ending clean mount
/var/log/messages:2537:Jan  4 17:21:07 clientserver kernel: XFS (dm-5): Ending clean mount
/var/log/messages:2844:Jan  4 17:21:24 clientserver mount: mount.nfs: access denied by server while mounting nfsserver.co.local:/datalake/analytics/org
/var/log/messages:2845:Jan  4 17:21:24 clientserver mount: mount.nfs: access denied by server while mounting nfsserver.co.local:/datalake/raw/org
/var/log/messages:2846:Jan  4 17:21:24 clientserver systemd: datalake-org-analytics.mount mount process exited, code=exited status=32
/var/log/messages:2847:Jan  4 17:21:24 clientserver systemd: Failed to mount /datalake/org/analytics.
/var/log/messages:2850:Jan  4 17:21:24 clientserver systemd: Unit datalake-org-analytics.mount entered failed state.
/var/log/messages:2851:Jan  4 17:21:24 clientserver systemd: datalake-org-raw.mount mount process exited, code=exited status=32
/var/log/messages:2852:Jan  4 17:21:24 clientserver systemd: Failed to mount /datalake/org/raw.
/var/log/messages:2853:Jan  4 17:21:24 clientserver systemd: Unit datalake-org-raw.mount entered failed state.
/var/log/messages:3014:Jan  4 17:21:27 clientserver dracut: Executing: /usr/sbin/dracut --hostonly --hostonly-cmdline --hostonly-i18n -o "plymouth dash resume ifcfg" --mount "/dev/mapper/centos_mapr001-root /sysroot xfs defaults,x-systemd.device-timeout=0" --no-hostonly-default-device -f /boot/initramfs-3.10.0-862.6.3.el7.x86_64kdump.img 3.10.0-862.6.3.el7.x86_64
/var/log/messages-20201227:3669:Dec 23 17:47:35 clientserver systemd: mapr.mount mounting timed out. Stopping.
/var/log/messages-20201227:3823:Dec 23 17:47:37 clientserver systemd: Unit mapr.mount entered failed state.
[root@clientserver ~]#
[root@clientserver ~]#
[root@clientserver ~]#
[root@clientserver ~]# tail -n 15 /var/log/dmesg
[  148.561016] piix4_smbus 0000:00:01.3: SMBus Host Controller at 0x700, revision 0
[  148.643519] sd 0:0:0:0: Attached scsi generic sg0 type 0
[  148.643580] sd 0:0:1:0: Attached scsi generic sg1 type 0
[  148.643639] sd 0:0:2:0: Attached scsi generic sg2 type 0
[  148.643846] sd 0:0:3:0: Attached scsi generic sg3 type 0
[  148.643907] sd 0:0:4:0: Attached scsi generic sg4 type 0
[  148.643962] sd 0:0:5:0: Attached scsi generic sg5 type 0
[  148.644030] sr 1:0:0:0: Attached scsi generic sg6 type 5
[  148.718917] ppdev: user-space parallel port driver
[  148.723858] Adding 8900604k swap on /dev/mapper/centos_mapr001-swap.  Priority:-1 extents:1 across:8900604k FS
[  148.865301] XFS (sda1): Mounting V5 Filesystem
[  149.497874] XFS (sda1): Ending clean mount
[  150.110208] XFS (dm-5): Mounting V5 Filesystem
[  150.190558] XFS (dm-5): Ending clean mount
[  150.966314] type=1305 audit(1609816868.676:4): audit_pid=2500 old=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:auditd_t:s0 res=1

Я могу ping машину nfsserver по имени и IP-адресу с клиента (и наоборот с машины nfsserver).

Проверяя настройки SE Linux, я вижу…

[root@clientserver /]$ sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   permissive
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      31

Я не настраивал это (и действительно не имею большого опыта с SE Linux), но “permissive” заставляет думать, что это не проблема с файерволом.

Слышал, что там могут быть проблемы с портами, которые могут вызвать подобные ситуации. Когда я использую rpcinfo, я вижу

[root@clientserver ~]# rpcinfo -p
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  34584  status
    100024    1   tcp  53605  status
    100005    1   udp  20048  mountd
    100005    1   tcp  20048  mountd
    100005    2   udp  20048  mountd
    100005    2   tcp  20048  mountd
    100005    3   udp  20048  mountd
    100005    3   tcp  20048  mountd
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    3   tcp   2049  nfs_acl
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100227    3   udp   2049  nfs_acl
    100021    1   udp  36667  nlockmgr
    100021    3   udp  36667  nlockmgr
    100021    4   udp  36667  nlockmgr
    100021    1   tcp  39608  nlockmgr
    100021    3   tcp  39608  nlockmgr
    100021    4   tcp  39608  nlockmgr

но я действительно не знаю много о сетевых вещах, чтобы сказать, нормально это или нет.

Смотрю на сервере nfsserver, я увидел:

[root@nfsserver ~]# cat /etc/exports
/datalake/analytics/org         otherclient(rw,no_root_squash,sync) clientserver(rw,root_squash,sync)
/datalake/raw/org               otherclient(rw,no_root_squash,sync) clientserver(ro,root_squash,sync)
/datalake/raw/org/HI_BRFSS      otherclient(ro,no_root_squash,sync) clientserver(ro,root_squash,sync)
[root@nfsserver ~]# exportfs -rav
exporting otherclient.co.local:/datalake/raw/org/HI_BRFSS
exporting clientserver.co.local:/datalake/raw/org/HI_BRFSS
exporting otherclient.co.local:/datalake/raw/org
exporting clientserver.co.local:/datalake/raw/org
exporting otherclient.co.local:/datalake/analytics/org
exporting clientserver.co.local:/datalake/analytics/org


[root@nfsserver ~]# systemctl status nfs
● nfs-server.service - NFS server and services
   Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; enabled; vendor preset: disabled)
   Active: active (exited) since Wed 2020-12-30 18:38:00 HST; 22min ago
  Process: 135417 ExecStopPost=/usr/sbin/exportfs -f (code=exited, status=0/SUCCESS)
  Process: 135414 ExecStopPost=/usr/sbin/exportfs -au (code=exited, status=0/SUCCESS)
  Process: 135412 ExecStop=/usr/sbin/rpc.nfsd 0 (code=exited, status=0/SUCCESS)
  Process: 135447 ExecStartPost=/bin/sh -c if systemctl -q is-active gssproxy; then systemctl reload gssproxy ; fi (code=exited, status=0/SUCCESS)
  Process: 135430 ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS (code=exited, status=0/SUCCESS)
  Process: 135428 ExecStartPre=/usr/sbin/exportfs -r (code=exited, status=0/SUCCESS)
 Main PID: 135430 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/nfs-server.service

Dec 30 18:38:00 nfsserver.co.local systemd[1]: Starting NFS server and services...
Dec 30 18:38:00 nfsserver.co.local systemd[1]: Started NFS server and services.

Так что, опять же, все, кажется, настроено как надо. (Видел некоторые ответы, которые рекомендуют специальную конфигурацию для /etc/exports, но я предпочитаю оставить как есть, и эта конфигурация работала до сих пор). Изменение DNS-имени на IP в файле /etc/exports на сервере nfsserver и выполнение exportfs -rav не изменили ситуацию.

Кто-нибудь с большим опытом знает, что может идти не так в этом случае? Любые дополнительные советы по отладке / информация для добавления, которые улучшат этот вопрос (например, может кто-то видит что-то в этом посте, где нужно провести дальнейшее расследование какой-то возможности)?

Если на вашем NFS сервере системный диск заполнен:

  1. вы получите сообщения mount.nfs: access denied by server while mounting на клиентах
  2. служба nfs будет выглядеть нормально с помощью systemctl status nfs-kernel-server
  3. логи, вероятно, не покажут ничего подозрительного (хотя может быть что-то явно неверное в логах, так как у вас кончилось место)

Публикуя этот ответ, так как симптомы очень похожи (внезапные необъяснимые ошибки ‘доступ запрещен’ при попытке примонтировать ресурсы NFS сервера, которые работали нормально на сервере, который отвечает на пинги и выглядит нормально)

Решение – все обычные действия, когда у вас заканчивается место – логи, контейнеры Docker и т. д.

.

Ответ или решение

Проблема, связанная с сообщением об ошибке "mount.nfs4: access denied by server while mounting", может быть вызвана множеством причин, особенно если конфигурация ранее работала без сбоев. Для системного администратора или ИТ-эксперта важно методично подходить к диагностике и устранению этой проблемы. Давайте подробно разберём каждую возможную причину и способ её решения, применяя методику TEA (Theory, Example, Application).

Теория (Theory)

Основная причина ошибки "доступ запрещен сервером" при монтировании NFS может заключаться в неправильных настройках разрешений на сервере, сетевых ошибках или проблемах с безопасностью. Проблема может возникать на стороне как клиента, так и сервера. Несмотря на то, что NFS был разработан как удобный и надёжный способ совместного использования файлов, он подвержен ошибкам конфигурации, вызванным как человеческим фактором, так и изменениями в среде системы.

  1. Настройки экспорта NFS: Некорректная запись в /etc/exports может привести к отказу в доступе. Ошибки в именах хостов, IP-адресах или права доступа могут влиять на возможность клиента монтировать ресурсы.

  2. Проблемы с DNS или IP-адресами: Изменения в DNS или IP-адресах после перезагрузки могут привести к несоответствию, вызывая ошибку доступа.

  3. Сетевые проблемы: Брандмауэры, как на сервере, так и на клиенте, могут заблокировать нужные порты или протоколы.

  4. SELinux и меры безопасности: SELinux может ограничивать доступ, если конфигурации не соответствуют его политике, даже в режиме "permissive".

  5. Проблемы с аутентификацией: Ошибки в GSSAPI, SSSD и Kerberos могут влиять на возможность монтирования, если произошли изменения в конфигурации аутентификации.

  6. Недостаток пространства на диске: Если на сервере NFS кончилось место на системном диске, это приведет к непредвиденным ошибкам доступа.

Пример (Example)

Рассмотрим сценарий, когда настроенный ранее NFS-сервер, после перезапуска, начал выдавать ошибку доступа при монтировании. Клиент пытается примонтировать файловую систему с помощью команды:

mount -t nfs -vvvv 172.18.4.97:/datalake/raw/org /datalake/org/raw/

Но сталкивается с отказом в доступе на всех версиях NFS. Тампдамп, проверка конфигураций, статуса NFS-сервисов и текущих политик SELinux показывают, что все в порядке, но монтирование не происходит. Вместе с тем в логах возникают ошибки GSSAPI, что указывает на проблемы с аутентификацией.

Применение (Application)

  1. Проверка конфигурации /etc/exports:

    • Убедитесь, что в списке экспорта серверов указаны правильные IP-адреса и имена хостов. Проверьте права доступа, например rw, ro, no_root_squash.
    • Обратите внимание на точное соответствие имени хоста или IP, как они отображаются клиенту.
  2. Диагностика сетевых проблем:

    • Используйте rpcinfo для проверки доступности NFS служебных служб и рабочих портов.
    • Проверьте брандмауэр на наличие необходимых открытых портов для NFS, таких как 2049 для передачи данных.
  3. Проверка SELinux:

    • Даже в "пермиссивном" режиме SELinux все равно может влиять на монтирования. Выполните проверку с помощью утилиты setenforce 0 временно для диагностики.
  4. Анализ GSSAPI/SSSD/Kerberos зависимостей:

    • Проверьте конфигурацию Kerberos и GSSAPI. Удостоверьтесь, что актуальны все учетные записи и ключи, необходимые для аутентификации. Возможно стоит перезапустить службы.
  5. Проверка на ошибки ‘out of space’:

    • Убедитесь, что на системном разделе сервера достаточно места. Это может быть причиной неожиданных отказов и сбоев.
  6. Обновление системного времени и времени на всех участках сети:

    • Убедитесь, что система времени синхронизирована между сервером и клиентом, так как различия могут нарушить процесс аутентификации.

Данная методика анализа и устранения проблемы поможет системному администратору разобраться с возникшей ошибкой и восстановить стабильную работу NFS-сервера. Важно помнить, что системное администрирование требует внимательности и терпения, а каждая возникающая ошибка — это возможность улучшить свои навыки и знания.

Оцените материал
Добавить комментарий

Капча загружается...