Первый создаваемый в системе пользователь с ID 1000 сразу включается в группу users, а с ней сарафаном ещё множество разных служебных групп, вроде 14(uucp),19(proc),22(cdrom),36(vmusers),71(floppy),80(cdwriter),81(audio),83(radio) и пр. Я добавлю пользователя в группу ved. Создаю каталог с правами записи для группы ved. stat /mnt/YandexDisk/Письма Файл: /mnt/YandexDisk/Письма Размер: 12288 Блоков: 24 Блок В/В: 1048576 каталог Устройство: 0/59 Инода: 109445121 Ссылки: 8 Доступ: (2775/drwxrwsr-x) Uid: ( 1003/ UNKNOWN) Gid: ( 1013/ ved) Но записать не могу! А вот если исключить пользователя из группы users — всё работает как надо!
(In reply to riverdome@yandex.ru from comment #0) > Первый создаваемый в системе пользователь с ID 1000 сразу включается в > группу users, а с ней сарафаном ещё множество разных служебных групп, вроде > 14(uucp),19(proc),22(cdrom),36(vmusers),71(floppy),80(cdwriter),81(audio), > 83(radio) и пр. И это хорошо. > Я добавлю пользователя в группу ved. > Создаю каталог с правами записи для группы ved. > > stat /mnt/YandexDisk/Письма Это какой-то fuse? На обычных каталогах (на ext4 например) воспроизводится? > Файл: /mnt/YandexDisk/Письма > Размер: 12288 Блоков: 24 Блок В/В: 1048576 каталог > Устройство: 0/59 Инода: 109445121 Ссылки: 8 > Доступ: (2775/drwxrwsr-x) Uid: ( 1003/ UNKNOWN) Gid: ( 1013/ ved) > > Но записать не могу! Вы точно перелогинивались после добавления пользователя в группу? Было бы полезно увидеть вывод команды id и ошибку записи в одном логе сессии командной строки.
Работа в каталоге, подключенном по NFS. Разумеется, перегружали и всякое пробовали, пока не нашли причину опытным путём. Повторяемость 100% на всех компьютерах, где ставили Альт. Локально не пробовали — просто нет такой задачи.
Разумеется, GID на стороне клиента такой же, как на сервере. Опыт есть. Уже с год используем несколько каталогов с разными GID для разделения доступов — всё хорошо работает, но только если исключать локального пользователя из группы users. Ну или создавать его не первым, что бы он в users не попадал.
Если сделать группу ved основной — запись работает. Но обычно пользователь состоит одновременно в нескольких группах, что бы иметь возможность записи в разные папки. Получается, что не применяются права дополнительных групп, если не исключить из users.
Не воспроизвёл: попробовал локально, попробовал через NFS. Не могли бы вы предоставить опции NFS в целях воспроизведения данной ошибки?
cat /etc/exports /srv/public -ro,insecure,no_subtree_check,fsid=0 192.168.0.0/16 /srv/public/YandexDisk -rw,insecure,no_subtree_check,fsid=1 192.168.0.0/16
Я вижу тесную связь с ошибкой #54890. Потому, что не применяется umask из /etc/profile. Вот живой пример: [victoriya@kasyanenko ~]$ id uid=500(victoriya) gid=1007(export) группы=1007(export),10(wheel),14(uucp),19(proc),22(cdrom),36(vmusers),71(floppy),80(cdwriter),81(audio),83(radio),100(users),439(usershares),446(camera),463(vboxusers),465(fuse),477(video),487(vboxsf),488(vboxadd),498(xgrp),499(scanner),1005(scan),1008(law) На NFS-шаре /srv/public/YandexDisk/Экспорт/... создаю две папки: 123 и 345. Первую через Dolphin, вторую — в консоли (mkdir). Права разные! ll итого 792 drwxrwsr-x 4 500 export 4096 июл 17 17:41 ./ drwxrwsr-x 2 500 export 4096 июл 17 17:41 345/ drwxr-sr-x 2 500 export 4096 июл 17 17:19 123/ 345 с правами записи для группы 123 — только чтение! А вот если исключить пользователя из группы users — всё работает правильно.
Не совсем точно выразился. В /etc/profile установлен umask 002. Он работает если создавать файлы через CLI, но не работает через GUI (в частности, Dolphin). Что бы права заработали через GUI, надо в /etc/pam.d/system-auth добавить строку session optional pam_umask.so usergroups и удалить пользователя из группы users.
[root@Dellissimo ~]# id natasha uid=1002(natasha) gid=1002(natasha) группы=1002(natasha),100(users),36(vmusers),939(usershares),80(cdwriter),22(cdrom),81(audio),972(video),19(proc),83(radio),940(camera),71(floppy),996(xgrp),997(scanner),14(uucp),956(vboxusers),958(fuse),988(vboxadd),987(vboxsf) [root@Dellissimo ~]# su - natasha [natasha@Dellissimo ~]$ ls /mnt/YandexDisk/ ScanFiles/ .Trash-1000/ .Trash-500/ .Trash-502/ Бухгалтерия/ ИФНС/ Секретарь/ Экспорт/ .sync/ .Trash-1003/ .Trash-501/ .Trash-503/ Договоры/ Письма Топ Грейн/ Сканы документов/ [natasha@Dellissimo ~]$ touch /mnt/YandexDisk/Экспорт/nata123 touch: невозможно выполнить touch для '/mnt/YandexDisk/Экспорт/nata123': Отказано в доступе [natasha@Dellissimo ~]$ exit выход [root@Dellissimo ~]# usermod -a natasha -G export [root@Dellissimo ~]# su - natasha [natasha@Dellissimo ~]$ touch /mnt/YandexDisk/Экспорт/nata123 touch: невозможно выполнить touch для '/mnt/YandexDisk/Экспорт/nata123': Отказано в доступе [natasha@Dellissimo ~]$ id uid=1002(natasha) gid=1002(natasha) группы=1002(natasha),14(uucp),19(proc),22(cdrom),36(vmusers),71(floppy),80(cdwriter),81(audio),83(radio),100(users),939(usershares),940(camera),956(vboxusers),958(fuse),972(video),987(vboxsf),988(vboxadd),996(xgrp),997(scanner),1007(export) [natasha@Dellissimo ~]$ exit выход [root@Dellissimo ~]# gpasswd -d natasha users Удаление пользователя natasha из группы users [root@Dellissimo ~]# su - natasha [natasha@Dellissimo ~]$ touch /mnt/YandexDisk/Экспорт/nata123 [natasha@Dellissimo ~]$ stat /mnt/YandexDisk/Экспорт/nata123 stat [natasha@Dellissimo ~]$ stat /mnt/YandexDisk/Экспорт/nata123 Файл: /mnt/YandexDisk/Экспорт/nata123 Размер: 0 Блоков: 0 Блок В/В: 1048576 пустой обычный файл Устройство: 0/63 Инода: 51520667 Ссылки: 1 Доступ: (0664/-rw-rw-r--) Uid: ( 1002/ natasha) Gid: ( 1007/ export) Доступ: 2025-07-20 21:22:36.684581633 +0300 Модифицирован: 2025-07-20 21:22:36.684581633 +0300 Изменён: 2025-07-20 21:22:36.684581633 +0300 Создан: - [natasha@Dellissimo ~]$ stat /mnt/YandexDisk/Экспорт/ Файл: /mnt/YandexDisk/Экспорт/ Размер: 4096 Блоков: 8 Блок В/В: 1048576 каталог Устройство: 0/63 Инода: 51511297 Ссылки: 4 Доступ: (2775/drwxrwsr-x) Uid: ( 1003/ UNKNOWN) Gid: ( 1007/ export) Доступ: 2025-07-20 21:22:37.684574164 +0300 Модифицирован: 2025-07-20 21:22:36.629582044 +0300 Изменён: 2025-07-20 21:22:36.629582044 +0300 Создан: -
Вот снова наглядно повторил. Добавил пользователя natasha в группу export с таким же gid, как на сервере. Папка /mnt/YandexDisk/Экспорт/ принадлежит группу export, но natasha записать туда не может. Но стоит удалить её из группы users — вуаля! Запись становится возможной!
1. Необходимы детали для воспроизаедения. Что-то осталось за кадром. Начать нужно с того, что используется NFS. Какие-то настройки приведены. А вот остальное окружение нужно как-то угадывать. Указывается локальный пользователь, значит имеются и не локальные пользователи. Здесь ничего не понятно. Что там freeipa, samba, ...? Возможно, это не самое важно. А возможно и нет. 2. Рассматриваются права на файлы для локальных пользователей. Но узлов-то, как минимум, два. Как поведет себя NFS, если gid'ы назначаемые пользователю на клиенте и на сервере будут рассинхронизированы? NFS устроен так, что доверие обеспечивается на уровне узлов. А значит и синхронизация uid'ов, gid'ов лежит на узлах. Предположу, что id выдает разных список групп на клиенте и на сервере. И, если на клиентах группа не назначена и/или бьется в разные имена и gid'ы, то модет быть проблема. В том числе и точки зрения отказа в обслуживании. Предлагаю более детально описать ситуацию с точки зрения назначаемых пользователю групп и их gid'ов на клиенте и на сервере. Назначение какой конкретно группы, прилетающей пользователю через users, на сервере вызывает отрицательный эффект. К сожалению, на текущий момент много частных деталей, но суть решаемой задачи скрыта за кадром, как самоочевидная. А парные клиентские и серверные настройки, степень их согласованности и другие детали не указаны. ______ Группы, в целом, назначаются пользователю только во время логина. Поскольку для клиента серверные настпойки применяются почти "мгновенно", то на клиенте может потребваться перелогин. Отсмотрел по тексту первое сообщение. Вас не смущает, что группа указана, как UNKNOWN?
Для начала, было интересно увидеть, для рассматривамого локального поьзователя, вывод id на клиенте и на сервере. Предположу, что вывод может оказаться разный, и gid'ы на разных узлах назначаются локальному пользователю разные. Вплоть до перечения и коллизий. ______ Еще один момент про umask. Тут тоже нужнв детали.
Если на NFS работают posix acl, то от костылей с umask и sgid я бы прдложил отказываться насовсем. В локальном режиме работы уже давно достаточно задать два права: - права на группу через acl; - дефолтные права на эту же группу через acl при создании новых файлов и каталогов.
На сервере: Alt Server 11 На клиентах: Alt 10 или 11 К На сервере через NFS открыт доступ к трём каталогам: два на чтение один (YandexDisk) — на запись. ALC не использую, хочу чуть позже настроить FreeIPA. Сейчас настройки минимальные. На сервере созданы группы: buh, export,ved и т.д. Для вложенных папок владельцем является пользователь srv (который входит во все эти группы), но разные группы. ll /srv/public/YandexDisk/ итого 180 drwxrwxr-x 3 srv srv 4096 июл 21 09:19 .sync/ drwxrwsr-x 26 srv buh 4096 июл 21 09:19 Бухгалтерия/ drwxrwsr-x 6 srv scan 4096 июл 21 09:07 ИФНС/ drwxrwsr-x 12 srv scan 98304 июл 21 09:04 'Сканы документов'/ drwxrwsr-x 4 srv export 4096 июл 21 04:02 Экспорт/ drwxrwsr-x 54 srv secretary 12288 июл 21 04:02 Секретарь/ drwxrwsr-x 8 srv ved 12288 июл 21 04:02 'Письма Топ Грейн'/ drwxrwsr-x 10 srv law 4096 июл 21 04:02 Договоры/ dr-xrwsr-x 8 srv srv 4096 июл 21 04:02 ScanFiles/ На клиентах скриптом создаются одноимённые группы с таким же GID, как на сервере. groupadd -g 1005 scan groupadd -g 1006 buh groupadd -g 1007 export groupadd -g 1008 law groupadd -g 1012 secretary groupadd -g 1013 ved groupadd -g 1016 fin ( 1003/ UNKNOWN ) означает, что на сервере нет пользователя с UID 1003. А вот название группы определяется: они совпадают у всех. Про umask всё написал в баге #54890. Добавить нечего. Есть тут связь или это два разных бага — не могу сказать.
Как выглядит вывод id для целевого пользователя на клиенте и на сервере?
id пользователя natasha на клиенте я показал в девятом сообщении. На сервере я создавал группы без привязки к клиентам. Сейчас владельцем всех папок является пользователь srv id srv uid=1003(srv) gid=1004(srv) группы=1004(srv),1006(buh),1007(export),1005(scan),1008(law),1012(secretary),1013(ved),1016(fin)
Давайте разбираться последовательно. libnss-role добавляет на основании правил пользователей в дополнительные группы. По сути, реализуя механизм группы в группах. Как наличие дополнительных групп влияет на поведение NFS. Как, вообще, себя ведёт NFS в случае коллизий по пересечению uid'ов b gid'ов на разных узлах, назначенных разным пользователям? Думаю стоит сравнить /etc/{passwd,group} на сервере и на клиенте. Подозреваю что их синхронизация может решить проблему. Из ваших вводных это трудно понять. Для начала, проще выключить libnss-role и проверить как себя поведёт NFS в этом случае. Но, даже если заработает, это не исключает возможности пересечения uid и gid на локальных узлах. $ grep ^group: /etc/nsswitch.conf group: files [SUCCESS=merge] sss systemd role $ sudo control libnss-role enabled $ sudo control libnss-role help enabled: Enable libnss-role module disabled: Disable libnss-role module $ sudo control libnss-role disabled $ grep ^group: /etc/nsswitch.conf group: files [SUCCESS=merge] sss systemd
Насколько я понял, NFS просто сличает UID и GID. Если что-то совпадает — предоставляются права. Т.е. ведёт себя как обычная локальная файловая система. Я с этим поведением не раз уже сталкивался. Повторяемость 100%. Попробуйте у себя: На сервере создайте папку, где владельцем будет vasya:toster На клиенте создайте группу toster с таким же GID, как на сервере. Добавьте пользователя в эту группу. Как дополнительную, не основную! Убедитесь, что запись есть. Теперь добавьте пользователя в группу users (добавится весь сарафан). Убедитесь, что записи нет. Если toster будет основной группой для клиентского пользователя — опыт не удастся, запись будет всегда.
Это, как раз, понятно. Пока я у себя не начал воспроизводить вашу проблему, предлагаю проверить и исключить (или подтвердить) хоть какую-то причастность libnss-role к вашей проблеме. Возможно не в нем дело. Для этого я привёл в комментарии #17 пример как отключить libnss-role.
Воспроизвёл без libnss-role. NFS смотрит первые 16 групп, это прописано в https://datatracker.ietf.org/doc/html/rfc5531. https://datatracker.ietf.org/doc/html/rfc5531 Например, я воспроизвёл данное поведение и без групп users (группа для доступа к NFS Share - leet с GID 1337): # id test2 uid=1001(test2) gid=1001(test2) группы=1001(test2),1337(leet),1358(zgroup1),1359(zgroup2),1360(zgroup3),1361(zgroup4),1362(zgroup5),1363(zgroup6),1364(zgroup7),1365(zgroup8),1366(zgroup9),1367(zgroup10),1368(zgroup11),1369(zgroup12),1370(zgroup13),1371(zgroup14),1372(zgroup15),1373(zgroup16),1374(zgroup17),1375(zgroup18),1376(zgroup19),1377(zgroup20),1378(agroup1),1379(agroup2),1380(agroup3),1381(agroup4),1382(agroup5),1383(agroup6),1384(agroup7),1385(agroup8),1386(agroup9),1387(agroup10),1388(agroup11),1389(agroup12),1390(agroup13),1391(agroup14),1392(agroup15),1393(agroup16),1394(agroup17),1395(agroup18),1396(agroup19),1397(agroup20),1200(fake1200),1201(fake1201),1202(fake1202),1203(fake1203),1204(fake1204),1205(fake1205),1206(fake1206),1207(fake1207),1208(fake1208),1209(fake1209),1210(fake1210),1211(fake1211),1212(fake1212),1213(fake1213),1214(fake1214),1215(fake1215),1216(fake1216),1217(fake1217),1218(fake1218),1219(fake1219),1220(fake1220),1221(fake1221),1222(fake1222),1223(fake1223),1224(fake1224),1225(fake1225),1226(fake1226),1227(fake1227),1228(fake1228),1229(fake1229),1230(fake1230),1231(fake1231),1232(fake1232),1233(fake1233),1234(fake1234),1235(fake1235),1236(fake1236),1237(fake1237),1238(fake1238),1239(fake1239),1240(fake1240),1241(fake1241),1242(fake1242),1243(fake1243),1244(fake1244),1245(fake1245),1246(fake1246),1247(fake1247),1248(fake1248),1249(fake1249),1250(fake1250) Варианты решения: - Либо уменьшать количество групп меньше 16. - Либо использовать ACL, как предложил Evgeny Sinelnikov в Комментарий #13. - Либо через --manage-gids. Ссылки: - https://learn.microsoft.com/ru-ru/azure/azure-netapp-files/auxiliary-groups - https://wiki.archlinux.org/title/NFS/Troubleshooting
О, 16 групп... Я не знал о таком. Благодарю! Значит это не баг. Думаю, имеет смысл добавить это в какой-то FAQ или выделить предупреждением в статье Wiki по правам на NFS.
(Ответ для riverdome@yandex.ru на комментарий #21) > О, 16 групп... > Я не знал о таком. Благодарю! > Значит это не баг. > Думаю, имеет смысл добавить это в какой-то FAQ или выделить предупреждением > в статье Wiki по правам на NFS. В вашем случае, я считаю, будет достаточно выполнить: # sed -i "s|# manage-gids=n|manage-gids=y|g" /etc/nfs.conf && systemctl restart nfs
(Ответ для Evgeny Shesteperov на комментарий #22) > В вашем случае, я считаю, будет достаточно выполнить: > # sed -i "s|# manage-gids=n|manage-gids=y|g" /etc/nfs.conf && systemctl > restart nfs А может, по умолчанию сделать в пакете nfs?
Думаю, тогда могут возникнуть тормоза при обращении к шаре. Скажу за себя. Я переживал, что либо я тупой, либо линукс недоделанный и тут всё так. Когда понял причину и понял как обходить — всё, душа спокойна. Предлагаю в дистрибутиве ничего не менять, а на Вики написать в рамочке, дескать, возможны такие грабли...
