Корень не может изменить разрешение файла или владение

Обычно корня не имеет специальных разрешений на акциях NFS. Напротив: root сопоставлен с обычным пользователем (то есть даже не имеет «нормального» доступа к чтению и записи в root файлов .

Вы должны запустить Chown на сервере NFS.

Обычно это случай, когда локальный пользователь корневого пользователя на клиентах NFS не разрешается выполнять эти виды деятельности на установленные NFS. NetApp, кажется, добавляет немного поворота в этом следующим образом:

• По умолчанию опция ANON указывает UID 65534. То есть, если вы не используете параметры root и Anon для ресурса, пользователей root Хосты Доступ к ресурсу с использованием UID 65534.
• Если параметр Anon указывает UID 65535, root-доступ отключен.
• Если опция ANON указывает UID 0, root Access предоставляется всем хостам.
• Если имя предусмотрено вместо UID, это имя рассматривается в соответствии с порядком, указанным в файле /etc/nsswitch.conf , чтобы определить соответствующий UID, который будет назначен опцией Anon Отказ

Итак, из внешности этого доля NetApp NFS имеет опцию по умолчанию, № 1. Вы можете подтвердить это, коснувшись файла на NFS, доля root, и увидев, какие идентификаторы результаты выполняют это.

Вы должны быть в состоянии увидеть экспортируемые параметры доли NFS, используя Mount -v на вашем клиенте NFS.

$ mount -v
...
mulder:/export/raid1/home/sam on /home/sam type nfs (rw,intr,tcp,nfsvers=3,rsize=16384,wsize=16384,addr=192.168.1.1)

Ссылки

• NFS: опция корня - сообщество NetApp

NFS-сервер NetApp по умолчанию изменит учетные данные пользователя root на клиенте на uid 65534 на сервере, поэтому такие операции, как chown, будут неудачны. Чтобы изменить это, отредактируйте список экспорта в файлере так, чтобы в строке для файловой системы был параметр root=clientid, где clientid - это IP-адрес или имя хоста клиента, к которому вы хотите получить корневой доступ в этой файловой системе. Затем запустите exportfs -a, если вы используете интерфейс командной строки в файлере.

Как slm комментарий выше,

It's typically the case that the local root user on NFS clients is disallowed from performing these types of activities on NFS mounted shares

Используемая функция называется гнилостной тыквой . Подробнее здесь . В моем случае единственным способом было войти в систему, чтобы отключить root squash для этого конкретного сервера и включить его позже.

С аналогичной ситуацией вы столкнетесь, если используете dockerконтейнер с томами, и контейнер работает с непривилегированным пользователем (, например.USER apache). Таким образом, идея, что точки монтирования NFS должны быть r/wтолько для owner, а не для root, является общепринятой практикой безопасности.

на хосте nfs

nano /etc/exports

/share       ip_of_client(rw,no_root_squash)

выход

exportfs -a

крепление

mount -t nfs host:/folder <mnt location>

Из РХЭЛ

By default, NFS shares change the root user to the nfsnobody user, an unprivileged user account. This changes the owner of all root-created files to nfsnobody, which prevents uploading of programs with the setuid bit set.

If no_root_squash is used, remote root users are able to change any file on the shared file system and leave applications infected by Trojans for other users to inadvertently execute.

Другим людям, столкнувшимся с такой же ошибкой, может быть полезно разблокировать файлы, если они были заблокированы ранее. Запустите это в каталоге, в котором находится ваша папка.

chattr -R -i yourFolderName

Это позволит вам изменить владельца и редактировать файлы внутри.