Значение по умолчанию NFS к 777

Параметр "umask" в /home/user/.profile управляет разрешениями, предоставляемыми файлу, созданному этим пользователем. Standart - umask=022, что означает 755 для файлов и 644 для каталогов. Если вы хотите, чтобы у владельца и группы были полные права, то это должно быть "umask=002"

Это требует более сложной обработки прав доступа, чем то, с чем UNIX может эффективно справиться. ACL файловых систем - ваше решение здесь.

Используя ACL, вы можете унаследовать права доступа от родительских каталогов, а также права собственности. Это гарантирует, что независимо от того, кто создал файлы или каталоги в определенном поддереве, они получат свои права от родительского каталога (а не от маски).

Изучите команды getfacl и setfacl. Используя ACL по умолчанию, вы можете контролировать это правообладание и наследование разрешений.

Эта глава руководства администратора хранилища RHEL является очень полным руководством по ACL, и это довольно определённый ресурс: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/ch-acls.html

Если код PHP может создавать файлы, он должен иметь возможность "chmod" их.

<?php
chmod("/mydir/myfile", 0660);
?>

Здесь ссылка на PHP-функцию chmod.

Если вы хотите смонтировать общий ресурс с определенным uid / gid (другой tah nobody / nogroup), вы можете попробовать выполнить экспорт с all_squash

/export/myshare x.x.x.x(rw,all_squash,anonuid=<newUID>,anongid=<newGID>,sync)

From https://linux.die.net/man/5/exports :

all_squash

Сопоставить все uid и gid анонимному пользователю. Полезно для экспортируемых через NFS общедоступных каталогов FTP, каталогов новостей и т. Д. противоположная опция - no_all_squash, которая является настройкой по умолчанию.

anonuid и anongid

Эти параметры явно устанавливают uid и gid анонимной учетной записи. Эта опция в первую очередь полезна для клиентов ПК / NFS, где вы может потребоваться, чтобы все запросы поступали от одного пользователя. Например, рассмотрите запись экспорта для / home / joe в приведенном ниже разделе примеров, который отображает все запросы на uid 150 (который предположительно принадлежит пользователю Джо).

Вы используете NFSv4. Жаль, что вы не указали версию своей ОС, поскольку здесь это будет очень важно.

В старых версиях NFS использовались строго номера UID / GID, поэтому сервер NFS мог не знать всех пользователей и группы на клиентах и ​​наоборот - пока номера UID / GID не конфликтовали, все было хорошо.

Но NFSv4 имеет возможность использовать имена пользователей / групп вместо номеров UID / GID . Если используются имена, они передаются в форме user @ domain , где domain обычно по умолчанию соответствует домену DNS каждой системы, но при необходимости может быть изменен на произвольную строку. Если настройки домена сервера NFSv4 и клиента (ов) NFSv4 не совпадают или сопоставление имени пользователя / группы не удается по какой-либо другой причине, вы, вероятно, увидите, что права собственности сопоставлены с none и права доступа к файлам сведены к минимуму - прямо как вы видите.

В Linux сопоставление имен пользователей и групп выполняется службой rpc.idmapd . Если эта служба не запущена, это также может быть причиной того, что права собственности на файлы отображаются на никто . В RHEL / CentOS / OEL 6.5 и более ранних этот демон должен работать как на клиентах, так и на серверах NFS. (Да, на стороне клиента есть программа вызова / usr / sbin / nfsidmap , которая должна сделать rpc.idmapd ненужным на стороне клиента NFS, начиная с версии 6.3 ... но она была ошибка, которая была исправлена ​​только в RHEL / CentOS / OEL 6.6 и новее.)

В Linux настройка домена NFS по умолчанию - DNS-имя домена хоста, но его можно изменить с помощью Domain = в файле /etc/idmapd.conf . А в RHEL 6.3 и старше была ошибка, из-за которой этот параметр игнорировался: если вы используете NFSv4, вам следует выполнить обновление до 6.4 или новее. После смены домена вы должны запустить nfsidmap -c в версии 6.3 и новее; в старых системах вам потребуется перезапустить демон rpc.idmapd и перемонтировать все монтирования NFS.

Если вы хотите отключить функцию отображения идентификаторов в NFSv4 и вместо этого вернуться к использованию в стиле NFSv3 только номеров UID / GID (что может быть полезно, если ваш сервер NFS, например, NAS-сервер, не имеющий информации об учетных записях пользователей на клиенте systems), вам необходимо убедиться, что параметр модуля ядра nfs nfsv4_disable_idmapping включен:

echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf

Этот параметр модуля существует в RHEL 6.3 и новее и должен быть включен по умолчанию , но лучше убедиться.

На стороне сервера возврат к поведению UID / GID в стиле NFSv3 в NFSv4 потребует двух вещей. Во-первых, аналогичная опция ядра должна быть проверена (или явно установлена) для модуля ядра nfsd :

echo "options nfsd nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf

Во-вторых, безопасность экспорта NFS должна быть sec = sys .

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

На NetApp NAS, настройка, позволяющая использовать числовые UID / GID значения в NFSv4:

options nfs.v4.id.allow_numerics on

или:

cluster::> set diag
cluster::*> nfs server modify -vserver vs0 -v4-numeric-ids enabled

в зависимости от версии NetApp.