Проблема видимости NFS: файлы в монтировании QNAP NAS невидимы для PHP (пользователь компании)

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

Недавний сбой системы, вызванный циклонным штормом, привел к постоянной проблеме, когда FileRun (веб-ориентированная система управления файлами) не может отображать файлы, хранящиеся в каталоге, смонтированном через NFS. Наша конфигурация состоит из накопителя QNAP NAS, который служит основным хранилищем, и сервера в AWS, где работает FileRun, подключенного к NAS через VPN-туннель.

NFS-монтаж активен, и файлы доступны через SSH, но PHP-скрипты, выполняемые под пользователем company-user, не могут видеть содержимое смонтированного каталога, в то время как root и nobody могут. Еще более странным является то, что файлы, создаваемые пользователем company-user в NFS-монтаже, видны только для company-user, но не для root или nobody. Это указывает на проблему видимости NFS, связанную с отображением идентификаторов пользователей или разрешениями, которая сохранялась даже после тщательных шагов отладки, включая перемонтирование с различными версиями NFS, модификацию idmapd.conf, настройку /etc/exports на NAS и ручное выравнивание сопоставлений UID/GID.

Я описал все необходимые шаги отладки, журналы и конфигурации ниже. Что может быть причиной этой диспропорции видимости для company-user? Любые идеи о возможных причудах, специфичных для NFS, проблемах конфигурации QNAP или факторах, связанных с Apache/PHP, будут весьма полезны.

Исходная информация:
– Клиент AWS для NFS использует CloudLinux 9.4, основанный на RHEL.
– SELinux был отключен задолго до появления проблемы.
– Точка монтирования, в случае сомнений: /home2/company-user/cloud.example.com/cloud/drive/NAS03
– До нижеупомянутой отладки файлы на QNAP NAS в основном были назначены администратору (группе администраторов) в соответствии с первоначальной настройкой. Другие пользователи со временем добавляли новые файлы и сохраняли их владение.

Архитектурный обзор текущей настройки:
– Локальный QNAP NAS: располагается в местной инфраструктуре компании, функционирует как централизованное хранилище данных компании, запускает сервер NFS (Network File System), что позволяет осуществлять обмен файлами по сети.
– Сервер AWS (Private Cloud): размещает инфраструктуру частного облака с использованием FileRun (веб-ориентированной системы управления файлами), служит точкой доступа для сотрудников компании, в частности для маркетинговой команды, для удаленного получения и управления файлами, подключается к QNAP NAS через VPN-туннель, позволяя бесшовную интеграцию NAS-хранилища в среду FileRun.

Проблема: после сбоя системы, вызванного циклоном в прошлые выходные, FileRun не может отобразить файлы, хранящиеся в смонтированной директории NAS (NAS03).

Наблюдения:
– Монтаж NFS активен и правильно настроен на AWS.
– Файлы доступны через SSH, когда перечисляются с использованием ls под определенными пользователями, в частности root и nobody.
– FileRun работает через Apache (nobody) и выполняет PHP-скрипты от имени company-user. Таким образом, Apache (nobody) может видеть файлы, но PHP (company-user) не может, что мешает FileRun их отображать.
– Когда root или nobody перечисляют каталог, все ожидаемые файлы видны, что подтверждает наличие данных и правильное функционирование монтирования.
– Однако, когда company-user перечисляет тот же каталог, он кажется пустым, что указывает на специфичную для пользователя проблему доступа или видимости.
– Если company-user создает новый файл или директорию внутри монтажа NAS, это видно только для company-user, как в CLI, так и в интерфейсе FileRun, но, очень странно, не видно для root или nobody.
– Эти вновь созданные файлы индексируются FileRun, что указывает на то, что FileRun, по крайней мере частично, осведомлен об изменениях в каталоге.

Это указывает на специфичную для пользователя проблему видимости NFS, вероятно вызванную скрытым механизмом контроля доступа на NAS, который изолирует файлы, созданные различными пользователями.

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

Проблема видимости файлов NFS на QNAP NAS, с которой вы столкнулись, действительно вызывает множество вопросов, и, судя по предоставленной информации, вы уже выполнили множество шагов по устранению неполадок. Давайте попробуем понять первопричину и возможные решения.

Теория

Первая линия проверки заключается в понимании того, как работает NFS и как реализуется доступ к файлам в этой системе. NFS (Network File System) позволяет монтировать удаленные файловые системы и работать с ними так, как с локальными. Однако, как и любая сетевая файловая система, NFS сталкивается с проблемами управления идентификацией пользователей (UID/GID) и разрешениями.

Главная проблема здесь кажется связанной с тем, что PHP, запускаемый под пользователем company-user, не видит файлы, которые другие пользователи, такие как root или nobody, могут видеть. Это может быть связано с NFS маппингом идентификаторов пользователей или с особенностями работы веб-сервера и его взаимодействия с системой.

Пример

В предоставленном вами контексте важно понять, как права доступа и собственность на уровне файловой системы QNAP и сервера AWS влияют на видимость файлов между различными пользователями. Уже были предприняты попытки изменения настройки NFS на QNAP, включая изменение параметров /etc/exports и пробу разных версий NFS. Тем не менее, это не решило проблему.

Предоставленный вами вывод результатов команды getfacl подтверждает отсутствие дополнительных ACL-рестрикций, что подтверждает: стандартных ACL ограничений, которые могут препятствовать доступу, нет. Но остаются вопросы по поводу маппинга идентификаторов пользователей и, возможно, неправильно настроенного NFS-сервера. Заодно обсудим и системные аспекты, так как ваши действия, такие как перезагрузка служб, не решали проблему.

Применение

1. Проверка SELinux и MAC: Убедимся, что на сервере AWS действительно отключён SELinux. Учитывая, что вы используете CloudLinux, основанный на RHEL, обратим внимание на настройку SELinux. Используем команду sestatus для проверки состояния. Если он включен, временно отключите его командой setenforce 0 и протестируйте снова.

2. Обновление конфигураций NFS:

   • Убедитесь, что параметры all_squash и anonuid/anongid настроены правильно. Они влияют на то, как NFS сервер маппит пользователей, и могут привести к проблемам видимости.
   • Попробуйте другие комбинации параметров не только на QNAP, но и на клиенте, тестируя их влияние методом исключения.

3. Проверка конфигурации Apache и PHP:

   • Обратите внимание на конфигурацию php-fpm, который управляет запуском PHP-скриптов. Подтвердите, что у него есть права доступа к монтируемой директории.
   • Убедитесь, что системд юнит файл для запуска Apache/PHP позволяет доступ к NFS. Например, добавьте правила для SELinux (httpd_nfs_t) или измените настройки запуска, если используется защита на основе политики Systemd.

4. Оптимизация маппинга UID/GID:

   • Проверьте, чтобы UID/GID company-user соответствовали как на NAS, так и на сервере AWS. Попробуйте временно создать пользователя с аналогичным UID/GID на QNAP для проверки.

5. Решение проблем с кэшированием:

   • Проблемы с кэшированием метаданных могут иногда влиять на видимость файлов. Убедитесь, что никаких проблем с кэшированием нет, и попробуйте полномасштабно почистить кэш, не только на уровне ОС, но и на уровне NFS (actimeo, no_cache, lookupcache=none).

6. Анализировать подробные логи:

   • Поднимите уровень журналирования NFS для более детального анализа. Это может потребовать изменения конфигурации как на стороне клиента, так и сервера. Посмотрите, какая информация фиксируется и есть ли аномалии.

Заключение

Необходимо глубже понять взаимодействие между сервером AWS и QNAP NAS, чтобы выявить корень проблемы с видимостью. Важной частью может быть проверка и корректировка всех параметров, связанных с UID/GID маппингом и разрешениями доступа. Это может потребовать последовательного и методичного подхода, исключающего одну потенциальную проблему за другой. Если все вышеприведенные шаги не приводят к решению, возможно, стоит связаться с технической поддержкой QNAP или более глубоко изучить специфику работы FileRun в связке с вашими текущими программными и аппаратными настройками.