55088 2025-07-07 10:31:00 +0300 Группа users влияет на права других групп 2025-07-31 12:34:54 +0300 1 1 1 Unclassified Branch p11 nfs unspecified x86_64 Linux CLOSED NOTABUG P5 normal --- 0 riverdome qa-team alimektor iv riverdome sbolshakov shevchenkodyu sin zerg qa-p11 oldest_to_newest 268467 0 riverdome 2025-07-07 10:31:00 +0300 Первый создаваемый в системе пользователь с 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 — всё работает как надо! 268473 1 iv 2025-07-07 11:04:45 +0300 (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 и ошибку записи в одном логе сессии командной строки. 268477 2 riverdome 2025-07-07 12:42:13 +0300 Работа в каталоге, подключенном по NFS. Разумеется, перегружали и всякое пробовали, пока не нашли причину опытным путём. Повторяемость 100% на всех компьютерах, где ставили Альт. Локально не пробовали — просто нет такой задачи. 268480 3 riverdome 2025-07-07 13:01:31 +0300 Разумеется, GID на стороне клиента такой же, как на сервере. Опыт есть. Уже с год используем несколько каталогов с разными GID для разделения доступов — всё хорошо работает, но только если исключать локального пользователя из группы users. Ну или создавать его не первым, что бы он в users не попадал. 268481 4 riverdome 2025-07-07 13:18:59 +0300 Если сделать группу ved основной — запись работает. Но обычно пользователь состоит одновременно в нескольких группах, что бы иметь возможность записи в разные папки. Получается, что не применяются права дополнительных групп, если не исключить из users. 269113 5 alimektor 2025-07-14 21:41:54 +0300 Не воспроизвёл: попробовал локально, попробовал через NFS. Не могли бы вы предоставить опции NFS в целях воспроизведения данной ошибки? 269355 6 riverdome 2025-07-18 00:31:43 +0300 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 269356 7 riverdome 2025-07-18 00:42:37 +0300 Я вижу тесную связь с ошибкой #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 — всё работает правильно. 269357 8 riverdome 2025-07-18 00:53:09 +0300 Не совсем точно выразился. В /etc/profile установлен umask 002. Он работает если создавать файлы через CLI, но не работает через GUI (в частности, Dolphin). Что бы права заработали через GUI, надо в /etc/pam.d/system-auth добавить строку session optional pam_umask.so usergroups и удалить пользователя из группы users. 269486 9 riverdome 2025-07-20 21:25:39 +0300 [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 Создан: - 269487 10 riverdome 2025-07-20 21:28:16 +0300 Вот снова наглядно повторил. Добавил пользователя natasha в группу export с таким же gid, как на сервере. Папка /mnt/YandexDisk/Экспорт/ принадлежит группу export, но natasha записать туда не может. Но стоит удалить её из группы users — вуаля! Запись становится возможной! 269496 11 sin 2025-07-21 03:40:45 +0300 1. Необходимы детали для воспроизаедения. Что-то осталось за кадром. Начать нужно с того, что используется NFS. Какие-то настройки приведены. А вот остальное окружение нужно как-то угадывать. Указывается локальный пользователь, значит имеются и не локальные пользователи. Здесь ничего не понятно. Что там freeipa, samba, ...? Возможно, это не самое важно. А возможно и нет. 2. Рассматриваются права на файлы для локальных пользователей. Но узлов-то, как минимум, два. Как поведет себя NFS, если gid'ы назначаемые пользователю на клиенте и на сервере будут рассинхронизированы? NFS устроен так, что доверие обеспечивается на уровне узлов. А значит и синхронизация uid'ов, gid'ов лежит на узлах. Предположу, что id выдает разных список групп на клиенте и на сервере. И, если на клиентах группа не назначена и/или бьется в разные имена и gid'ы, то модет быть проблема. В том числе и точки зрения отказа в обслуживании. Предлагаю более детально описать ситуацию с точки зрения назначаемых пользователю групп и их gid'ов на клиенте и на сервере. Назначение какой конкретно группы, прилетающей пользователю через users, на сервере вызывает отрицательный эффект. К сожалению, на текущий момент много частных деталей, но суть решаемой задачи скрыта за кадром, как самоочевидная. А парные клиентские и серверные настройки, степень их согласованности и другие детали не указаны. ______ Группы, в целом, назначаются пользователю только во время логина. Поскольку для клиента серверные настпойки применяются почти "мгновенно", то на клиенте может потребваться перелогин. Отсмотрел по тексту первое сообщение. Вас не смущает, что группа указана, как UNKNOWN? 269497 12 sin 2025-07-21 03:48:09 +0300 Для начала, было интересно увидеть, для рассматривамого локального поьзователя, вывод id на клиенте и на сервере. Предположу, что вывод может оказаться разный, и gid'ы на разных узлах назначаются локальному пользователю разные. Вплоть до перечения и коллизий. ______ Еще один момент про umask. Тут тоже нужнв детали. 269498 13 sin 2025-07-21 03:56:34 +0300 Если на NFS работают posix acl, то от костылей с umask и sgid я бы прдложил отказываться насовсем. В локальном режиме работы уже давно достаточно задать два права: - права на группу через acl; - дефолтные права на эту же группу через acl при создании новых файлов и каталогов. 269502 14 riverdome 2025-07-21 09:30:41 +0300 На сервере: 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. Добавить нечего. Есть тут связь или это два разных бага — не могу сказать. 269523 15 sin 2025-07-21 12:49:16 +0300 Как выглядит вывод id для целевого пользователя на клиенте и на сервере? 269660 16 riverdome 2025-07-22 20:58:10 +0300 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) 269661 17 sin 2025-07-22 21:22:15 +0300 Давайте разбираться последовательно. 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 269663 18 riverdome 2025-07-22 21:47:42 +0300 Насколько я понял, NFS просто сличает UID и GID. Если что-то совпадает — предоставляются права. Т.е. ведёт себя как обычная локальная файловая система. Я с этим поведением не раз уже сталкивался. Повторяемость 100%. Попробуйте у себя: На сервере создайте папку, где владельцем будет vasya:toster На клиенте создайте группу toster с таким же GID, как на сервере. Добавьте пользователя в эту группу. Как дополнительную, не основную! Убедитесь, что запись есть. Теперь добавьте пользователя в группу users (добавится весь сарафан). Убедитесь, что записи нет. Если toster будет основной группой для клиентского пользователя — опыт не удастся, запись будет всегда. 269664 19 sin 2025-07-22 21:54:17 +0300 Это, как раз, понятно. Пока я у себя не начал воспроизводить вашу проблему, предлагаю проверить и исключить (или подтвердить) хоть какую-то причастность libnss-role к вашей проблеме. Возможно не в нем дело. Для этого я привёл в комментарии #17 пример как отключить libnss-role. 270093 20 alimektor 2025-07-30 13:14:01 +0300 Воспроизвёл без 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 270096 21 riverdome 2025-07-30 13:21:07 +0300 О, 16 групп... Я не знал о таком. Благодарю! Значит это не баг. Думаю, имеет смысл добавить это в какой-то FAQ или выделить предупреждением в статье Wiki по правам на NFS. 270100 22 alimektor 2025-07-30 13:26:16 +0300 (Ответ для riverdome@yandex.ru на комментарий #21) > О, 16 групп... > Я не знал о таком. Благодарю! > Значит это не баг. > Думаю, имеет смысл добавить это в какой-то FAQ или выделить предупреждением > в статье Wiki по правам на NFS. В вашем случае, я считаю, будет достаточно выполнить: # sed -i "s|# manage-gids=n|manage-gids=y|g" /etc/nfs.conf && systemctl restart nfs 270103 23 zerg 2025-07-30 13:38:09 +0300 (Ответ для Evgeny Shesteperov на комментарий #22) > В вашем случае, я считаю, будет достаточно выполнить: > # sed -i "s|# manage-gids=n|manage-gids=y|g" /etc/nfs.conf && systemctl > restart nfs А может, по умолчанию сделать в пакете nfs? 270186 24 riverdome 2025-07-31 12:34:54 +0300 Думаю, тогда могут возникнуть тормоза при обращении к шаре. Скажу за себя. Я переживал, что либо я тупой, либо линукс недоделанный и тут всё так. Когда понял причину и понял как обходить — всё, душа спокойна. Предлагаю в дистрибутиве ничего не менять, а на Вики написать в рамочке, дескать, возможны такие грабли...