(Ответ для riverdome@yandex.ru на комментарий #0)
> https://www.spinics.net/linux/fedora/fedora-kde/msg21769.html
pam_umask.so есть в /etc/pam.d/systemd-run0, но не вижу, чтоб он где-то цеплялся.

Версия

-   pam-config-1.9.1-alt1

Шаги воспроизведения

Изменить /etc/profile.

    # sed -iE 's|umask .*|umask 002|g' /etc/profile

Создать папку testfolder через Dolphin.

Проверить папку:

    $ stat testfolder

Ожидаемый результат: создана папка с правами 0775/drwxrwxr-x

Фактический результат: создана папка с правами 0755/drwxr-xr-x

Воспроизводится в P11.

Вы не находите странным нежелание решать проблему неиспользования /etc/profile?
Там не только и не столько umask выставляется.

Перевесьте, пожалуйста, на Dolphin.

(Ответ для Dmitry V. Levin на комментарий #3)
> Вы не находите странным нежелание решать проблему неиспользования
> /etc/profile?
> Там не только и не столько umask выставляется.
> 
> Перевесьте, пожалуйста, на Dolphin.

Вроде никто не отказывался. Все признали наличие неполадки.
Почему надо перевешивать на Dolphin, если дело в pam.d ?
Или я что-то не понял?

Есть ещё одна странность.
При установке umask 002 в /etc/profile, эта настройка применяется ко всем пользователям, кроме первого (с uid=1000).
Я не уверен, что дело в uid и вообще нет каких-то предположений о причинах.
Просто наблюдение:

$ cat /etc/profile
umask 002
$ umask 
0022

А вот в сеансе root (и других пользователей) всё правильно:
# umask 
0002

После добавления строки
session		optional	pam_umask.so	usergroups
в /etc/pam.d/system-auth вывод umask становится правильным у первого тоже.

(Ответ для Dmitry V. Levin на комментарий #3)
> Перевесьте, пожалуйста, на Dolphin.
/usr/lib/systemd/user/plasma-dolphin.service
Можно перевесить только на systemd, иначе придётся перевешивать на каждый конечный софт.

Да, действительно больше похоже на проблему с systemd

Я, кстати, уже костылил это. https://git.altlinux.org/gears/p/plasma-workspace.git?p=plasma-workspace.git;a=blob;f=alt-run-etc-profile.patch

Created attachment 18913 [details]
To source or not to source?..

И вот ещё.
Первый создаваемый в системе пользователь с 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 — всё работает как надо!
Что это — баг или фича?

(Ответ для riverdome@yandex.ru на комментарий #10)
> И вот ещё.
Тут не надо. Создайте отдельный баг.

(Ответ для Sergey V Turchin на комментарий #11)
> (Ответ для riverdome@yandex.ru на комментарий #10)
> > И вот ещё.
> Тут не надо. Создайте отдельный баг.

Я просто не знаю, это связано с исходным или нет?
Если нет, то какой продукт/компонент указать при создании новой заявки?

(Ответ для riverdome@yandex.ru на комментарий #12)
> какой продукт/компонент указать при создании новой заявки?
p11/libnss-role

Создал баг #55088, но сдаётся мне, что эти две ошибки — суть одна.

Что бы права заработали через GUI, надо в /etc/pam.d/system-auth не только добавить строку
session		optional	pam_umask.so	usergroups
но так же удалить пользователя из группы users.

Не уверен, что это всегда так, продолжаю наблюдение.

#55088 оказался не багом.

NFS смотрит первые 16 групп, это прописано в https://datatracker.ietf.org/doc/html/rfc5531