Стенд

-   ALT Workstation 11 (Sisyphus)
-   Windows Server 2019

Версия

-   gpupdate-0.11.4-alt1
-   autofs-5.1.9-alt3

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

TLDR: связано с опцией cifsacl

1.  Создать пару подразделений (OU1, OU2).
2.  Создать по группе для данных подразделений соответственно
    (group_ou1, group_ou2)
3.  Создать по пользователю для данных подразделений соответственно
    (user_ou1, user_ou2).
4.  Добавить данных пользователей в только что созданные группы
    соответственно (user_ou1 в group_ou1, user_ou2 в group_ou2).
5.  Создать сетевую шару на сервере (C:/share) с правами чтения для
    всех.
6.  Создать подпапки для с доступом Чтение и запись только для созданных
    групп.
    1.  C:/share/ou1 для group_ou1
    2.  C:/share/ou2 для group_ou2
7.  Согласно документации 10.5.7. Подключение сетевых дисков
    (https://docs.altlinux.org/ru-RU/domain/10.4/html/group-policy/drives.html)
    настроить сетевой диск для C:/share (пользовательская политика).
8.  Применить групповые политики: # gpupdate && gpoa и $ gpupdate.
9.  Войти пользователем user_ou1 на тестовой машине.
10. В файловом менеджере перейти по пути
    /run/media/user_ou1/drives/share/ou1
11. Создать папку user_ou1.
12. Проверить права созданной папки:
    # stat /run/media/user_ou1/drives/share/ou1/user_ou1/ -c %A

Ожидаемый результат: папка доступна на чтение и запись.

Фактический результат: папка недоступна на чтение и запись (d---------).

Сравните права в данной примере

1 - созданная папка с правами

    # stat /run/media/user_ou1/drives/share/ou1/ -c %A
    drwx-----T

2 - созданная доменным пользователем в данной папке

    # stat /run/media/user_ou1/drives/share/ou1/user_ou1/ -c %A
    d---------

При создании папки из под Windows права не изменяются, то есть
наследование прав не работает:

    # stat /run/media/user_ou1/drives/share/ou1/win_user_ou1 -c %A
    d---------

Дополнительно: если убираю опцию cifsacl, то всё выглядит корректно:

    # echo '+dir:/etc/auto.test' >> /etc/auto.master
    # mkdir -p /etc/auto.test && \
    echo '"share" -fstype=cifs,cruid=$USER,sec=krb5,noperm ://dc/share' > /etc/auto.test/test.conf && \
    echo '/mnt/testcifs /etc/auto.test/test.conf --browse' > /etc/auto.test/test.autofs
    # systemctl restart autofs.service
    $ stat /mnt/testcifs/share/ou1/user2_ou1/ -c %A
    drwxr-xr-x
    $ mkdir -p /mnt/testcifs/share/ou1/new/ && \
    stat /mnt/testcifs/share/ou1/new/ -c %A
    drwxr-xr-x


Воспроизводится в P10

Добрый день!
Можно уточнить ориентировочные сроки по разрешению данной проблемы?

(In reply to Evgeny Shesteperov from comment #1)
> Стенд
> 
> -   ALT Workstation 11 (Sisyphus)
> -   Windows Server 2019
> 
> Версия
> 
> -   gpupdate-0.11.4-alt1
> -   autofs-5.1.9-alt3
> 
> Шаги воспроизведения
> 
> TLDR: связано с опцией cifsacl
> 
> 1.  Создать пару подразделений (OU1, OU2).
> 2.  Создать по группе для данных подразделений соответственно
>     (group_ou1, group_ou2)
> 3.  Создать по пользователю для данных подразделений соответственно
>     (user_ou1, user_ou2).
> 4.  Добавить данных пользователей в только что созданные группы
>     соответственно (user_ou1 в group_ou1, user_ou2 в group_ou2).
> 5.  Создать сетевую шару на сервере (C:/share) с правами чтения для
>     всех.
> 6.  Создать подпапки для с доступом Чтение и запись только для созданных
>     групп.
>     1.  C:/share/ou1 для group_ou1
>     2.  C:/share/ou2 для group_ou2
> 7.  Согласно документации 10.5.7. Подключение сетевых дисков
>    
> (https://docs.altlinux.org/ru-RU/domain/10.4/html/group-policy/drives.html)
>     настроить сетевой диск для C:/share (пользовательская политика).
> 8.  Применить групповые политики: # gpupdate && gpoa и $ gpupdate.
> 9.  Войти пользователем user_ou1 на тестовой машине.
> 10. В файловом менеджере перейти по пути
>     /run/media/user_ou1/drives/share/ou1
> 11. Создать папку user_ou1.
> 12. Проверить права созданной папки:
>     # stat /run/media/user_ou1/drives/share/ou1/user_ou1/ -c %A
> 
> Ожидаемый результат: папка доступна на чтение и запись.
> 
> Фактический результат: папка недоступна на чтение и запись (d---------).
> 
> Сравните права в данной примере
> 
> 1 - созданная папка с правами
> 
>     # stat /run/media/user_ou1/drives/share/ou1/ -c %A
>     drwx-----T
> 
> 2 - созданная доменным пользователем в данной папке
> 
>     # stat /run/media/user_ou1/drives/share/ou1/user_ou1/ -c %A
>     d---------
> 
> При создании папки из под Windows права не изменяются, то есть
> наследование прав не работает:
> 
>     # stat /run/media/user_ou1/drives/share/ou1/win_user_ou1 -c %A
>     d---------
> 
> Дополнительно: если убираю опцию cifsacl, то всё выглядит корректно:
> 
>     # echo '+dir:/etc/auto.test' >> /etc/auto.master
>     # mkdir -p /etc/auto.test && \
>     echo '"share" -fstype=cifs,cruid=$USER,sec=krb5,noperm ://dc/share' >
> /etc/auto.test/test.conf && \
>     echo '/mnt/testcifs /etc/auto.test/test.conf --browse' >
> /etc/auto.test/test.autofs
>     # systemctl restart autofs.service
>     $ stat /mnt/testcifs/share/ou1/user2_ou1/ -c %A
>     drwxr-xr-x
>     $ mkdir -p /mnt/testcifs/share/ou1/new/ && \
>     stat /mnt/testcifs/share/ou1/new/ -c %A
>     drwxr-xr-x
> 
> 
> Воспроизводится в P10

Без использования autofs, с ручным монтированием -- работает ?

Да, при подключении через проводник Dolphin проблем никаких нет, я для удобства сделал типа внутрикорпоративного сайта чтобы оттуда подключали по ссылке, только что приходится учетные данные вводить с указанием fqnd, по регламенту пользователям приходится менять пароли каждые 3 месяца, это неудобно для пользователей, ну и вызывает проблему для определенных пользователей.

У нас в cifs воспроизводится подобная проблема и на каталоге и на файлах.
По каталогу после создания его не видно, но если создать ещё раз то скажет что такой каталог уже существует
И файл также кто работал с ним его не видит, на соседнем компьютере его видно.

Перезагрузка ПК помогает увидеть всё что ищут

Здравствуйте Сергей, исправление попадет в gpupdate версии 0.12.2-alt1?

Предположу, что к gpupdate текущая проблема никакого отношения не имеет.

Сравнивать монтирование шары через cifs или подключение через Dolphin (а также любой другой файловый менеджер) стоит так:

1) Подключение через файловый менеджер аналогично переходу по UNC-пути в Windows:
smb://server/shara/directory (для сетевой папки \\server\shara\directory)

2) Монтирование шары через cifs соответствует подключению сетевого диска (autofs тут не имеет особого значения, он только автоматизирует подключение):
X:\directory (к шаре \\server\shara)

gpupdate делает второе, а вы пишите (если я правильно понял), что первое работает, а второе - нет. Так это разные механизмы и к gpupdate явно они не относятся.

Версия autofs для монтирования шары через cifs не особо существенна. Существенна версия ядра и драйвер cifs.ko, который идёт в составе ядра. Могут быть существенны опции монтирования.

Смотреть права в Dolphin, вообще, не имеет особого смысла - он просто так не умеет. Права применяются на сервере и, если там применено хитрое наследование, в рамках файловой системы NTFS, то через протокол SMB, в преобразованных правах в клиенте для сетевой файловой системы cifs, уже показывается оторванное от реальности на сервере состояние.

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

При этом стоит учитывать, что для шары на линуксовом сервере Samba поведение и настройки будут, скорее всего, другими.

Источник проблемы, скорее всего, в том, что линуксовый клиент неправильно "угадывает" созданные права на сервере, неправильно их задаёт в памяти после создания папки, но правильно их вычитывает после переподключения.

Решение этой проблемы, так или иначе, сводится к исправлению кода ядра и драйвера cifs.

Для полного анализа проблемы, её нужно описать в деталях для воспроизведения. И, прежде всего, так, чтобы правильно были настроены права на сервере. Желательны соответствующие скрины.

Никаким обновлением gpupdate, скорее всего, эту проблему решить не удастся. Если только не подобрать дополнительные опции монтирования шары (подключения сетевого диска в термиологии windows). А для этого нужно не в Dolphin шару smb://server/shara/directory проверять, а через ручной mount:

# mount -t cifs //server/shara /PATH_TO_MOUNTPOINT -o cruid=USERNAME,sec=krb5,noperm,cifsacl

где USERNAME - это имя пользователя, для которого монтируется шара, а /PATH_TO_MOUNTPOINT - каталог, в который монтируется шара (аналог имени сетевого диска, только как подкаталог, где будет отображаться содержимое шары после успешного монтирования).

Ещё один вариант - это задавать опции для шаблона настроек autofs в gpupdate в файле:
/usr/share/gpupdate/templates/autofs_mountpoints.j2

Вот если удастся при отладке получить желаемое поведение теми или иными опциями монтирования, то эти опции можно добавить в gpupdate. А иначе текущая проблема - это недоработка драйвера cifs. И к самому gpupdate или вспомогательному инструменту autofs отношения не имеет.

Задача озаглавлена "Нарушение унаследования прав на сетевых ресурсах при использовании опции cifsacl". Правильно ли, что без использования опции cifsacl, проблема не возникает?

Для проверки достаточно убрать эту опцию из файлов:
$ grep -R cifsacl /usr/share/gpupdate/templates/
/usr/share/gpupdate/templates/autofs_mountpoints_hide.j2:"{{ drv.label }}"	-fstype=cifs,cruid=$USER,sec=krb5,noperm,cifsacl	:{{ drv.path }}
/usr/share/gpupdate/templates/autofs_mountpoints_hide.j2:"{{ drv.dir }}"	-fstype=cifs,cruid=$USER,sec=krb5,noperm,cifsacl	:{{ drv.path }}
/usr/share/gpupdate/templates/autofs_mountpoints.j2:"{{ drv.label }}"	-fstype=cifs,cruid=$USER,sec=krb5,noperm,cifsacl	:{{ drv.path }}
/usr/share/gpupdate/templates/autofs_mountpoints.j2:"{{ drv.dir }}"	-fstype=cifs,cruid=$USER,sec=krb5,noperm,cifsacl	:{{ drv.path }}

Далее, после переподключения (ну, или после ребута), этих опций не будет.

Решает ли это заявленную проблему?

(Ответ для Evgeny Sinelnikov на комментарий #8)
> Задача озаглавлена "Нарушение унаследования прав на сетевых ресурсах при
> использовании опции cifsacl". Правильно ли, что без использования опции
> cifsacl, проблема не возникает?
> 
> Для проверки достаточно убрать эту опцию из файлов:
> $ grep -R cifsacl /usr/share/gpupdate/templates/
> /usr/share/gpupdate/templates/autofs_mountpoints_hide.j2:"{{ drv.label }}"
> -fstype=cifs,cruid=$USER,sec=krb5,noperm,cifsacl	:{{ drv.path }}
> /usr/share/gpupdate/templates/autofs_mountpoints_hide.j2:"{{ drv.dir }}"
> -fstype=cifs,cruid=$USER,sec=krb5,noperm,cifsacl	:{{ drv.path }}
> /usr/share/gpupdate/templates/autofs_mountpoints.j2:"{{ drv.label }}"
> -fstype=cifs,cruid=$USER,sec=krb5,noperm,cifsacl	:{{ drv.path }}
> /usr/share/gpupdate/templates/autofs_mountpoints.j2:"{{ drv.dir }}"
> -fstype=cifs,cruid=$USER,sec=krb5,noperm,cifsacl	:{{ drv.path }}
> 
> Далее, после переподключения (ну, или после ребута), этих опций не будет.
> 
> Решает ли это заявленную проблему?

Здравствуйте Евгений, вы все абсолютно правильно поняли, без опции cifsacl проблем нет, при таком раскладе абсолютно свободно как и Widows гуляешь в обменниках  с отключенным унаследованием прав на каталогах,
Только я не знаю на сколько данный вариант приемлем, по данному багу у меня сейчас открыт тикет в техподдержке, где как вариант я предложил убирать скриптом данную опцию логон скриптом при выключении хоста после обновления
Пример:
#!/bin/bash

# Автообновление
apt-get update && apt-get dedup -y && apt-get dist-upgrade -y && update-kernel -y
# Удаление опции cifsacl
# Путь к файлу
FILE_PATH="/usr/share/gpupdate/templates/autofs_mountpoints.j2"
# Текст, который нужно вырезать
TEXT_TO_REPLACE=",cifsacl"
# Основная функция замены текста
replace_text() {
    sed -i.bak "s/$TEXT_TO_REPLACE//g" "$FILE_PATH"
}
# Запуск функций
replace_text

И еще одно предложение, рассмотреть возможность реализации в ADMX шаблонах опцию включения или отключения типа cifsacl on (off) ели опция нужна будет в других случаях
На данный момент для проверки я убрал на 3 хостах вручную данную опцию, всe вроде хорошо, но опять же повторюсь, на сколько корректный данный подход?
Еще как альтернативу предложили на ваших еженедельных курсах по вторникам, рассмотреть вариант монтирования с помощью gio, но пока руки не дошли.

Евгений, хотел дополнить, что удаление опции произвел только в /usr/share/gpupdate/templates/autofs_mountpoints.j2", а не во всем представленном Вами перечне.

(Ответ для Murat на комментарий #9)
> (Ответ для Evgeny Sinelnikov на комментарий #8)
>
> И еще одно предложение, рассмотреть возможность реализации в ADMX шаблонах
> опцию включения или отключения типа cifsacl on (off) ели опция нужна будет в
> других случаях
> На данный момент для проверки я убрал на 3 хостах вручную данную опцию, всe
> вроде хорошо, но опять же повторюсь, на сколько корректный данный подход?
> Еще как альтернативу предложили на ваших еженедельных курсах по вторникам,
> рассмотреть вариант монтирования с помощью gio, но пока руки не дошли.


Добрый день, Мурат. В следующих версиях gpupdate и admx-basealt будет реализована политика и обработка отключения опции cifsacl.

gpupdate-0.13.0-alt1 -> sisyphus:

 Thu Mar 06 2025 Valery Sinelnikov <greh@altlinux> 0.13.0-alt1
 - Implemented Local Administrator Password Solution (LAPS) functionality,
   including support for Group Policy Object (GPO) keys to
   configure LAPS settings
 - Added support for disabling cifsacl in autofs mounts (closes:52333)
 - Implemented the ability to merge computer and user GPO shortcuts
 - Added access restrictions to network directories of other users
 - Added cleaning functionality for the autofs configuration catalog
 - Added ability to configure KDE 6 files

Для  including support for Group Policy Object (GPO) keys to
   configure LAPS settings вы в документации обновление сделаете?

https://www.altlinux.org/Групповые_политики
(Установка пароля для локального пользователя root	Не реализовано)
https://www.altlinux.org/Групповые_Политики/Установка_пароля_root

Версия пакета: gpupdate-0.13.2-alt1

Опция cifsacl с помощью групповой политики не отключается(https://bugzilla.altlinux.org/53920), данная ошибка актуальна.

(Ответ для Kostevich Arseniy на комментарий #14)
> Версия пакета: gpupdate-0.13.2-alt1
> 
> Опция cifsacl с помощью групповой политики не
> отключается(https://bugzilla.altlinux.org/53920), данная ошибка актуальна.

Добрый день. Данная ошибка на моём стенде не воспроизводится.

Версии пакетов:
gpupdate-0.13.2-alt1
admx-basealt-0.4.0-alt1


Прошу описать подробные шаги воспроизведения.

Ошибка воспроизводится по шагам из https://bugzilla.altlinux.org/show_bug.cgi?id=52333#c1
(Ответ для Evgeny Shesteperov на комментарий #1)
> Шаги воспроизведения
> 
> TLDR: связано с опцией cifsacl
> 
> 1.  Создать пару подразделений (OU1, OU2).
> 2.  Создать по группе для данных подразделений соответственно
>     (group_ou1, group_ou2)
> 3.  Создать по пользователю для данных подразделений соответственно
>     (user_ou1, user_ou2).
> 4.  Добавить данных пользователей в только что созданные группы
>     соответственно (user_ou1 в group_ou1, user_ou2 в group_ou2).
> 5.  Создать сетевую шару на сервере (C:/share) с правами чтения для
>     всех.
> 6.  Создать подпапки для с доступом Чтение и запись только для созданных
>     групп.
>     1.  C:/share/ou1 для group_ou1
>     2.  C:/share/ou2 для group_ou2
> 7.  Согласно документации 10.5.7. Подключение сетевых дисков
>  
> (https://docs.altlinux.org/ru-RU/domain/10.4/html/group-policy/drives.html)
>     настроить сетевой диск для C:/share (пользовательская политика).
В gpui настроена политика:
Пользователь → Настройки → Настройки системы → Сетевые диски -> Новый сетевой диск.
Путь: \\addc\share
Переподключиться: отметить чекбокс
Название: cshare
> 8.  Применить групповые политики: # gpupdate && gpoa и $ gpupdate.
> 9.  Войти пользователем user_ou1 на тестовой машине.
> 10. В файловом менеджере перейти по пути
>     /run/media/user_ou1/drives/share/ou1
> 11. Создать папку user_ou1.
> 12. Проверить права созданной папки:
>     # stat /run/media/user_ou1/drives/share/ou1/user_ou1/ -c %A
После выполнения шагов вывод stat:
d--------- 2 user_ou1 пользователи домена 0 июн 17 15:55 user_ou1/

Опция cifsacl включена по умолчанию:
# cat /etc/auto.master.gpupdate.d/S-1-5-21-1604496143-826943209-2064588331-1114.conf | grep cifsacl
"cshare" -fstype=cifs,cruid=$USER,sec=krb5,noperm,cifsacl ://addc/share

13. После этого настроил политику отключения cifsacl(Заметил, что в https://bugzilla.altlinux.org/53920 не были указаны все шаги, дополнил https://bugzilla.altlinux.org/show_bug.cgi?id=53920#c1):
Включил Компьютер -> Административные шаблоны -> Система ALT -> Групповые политики -> Экспериментальные групповые политики
Включил Компьютер -> Административные шаблоны -> Система ALT -> Монтирование -> Отключение аргумента cifsacl 
14. Применил политики # gpupdate && gpoa && reboot.
15. После перезагрузки зашёл пользователем user_ou1 и создал новую директорию /run/media/user_ou1/drives/cshare/ou1/testdir
# l /run/media/user_ou1/drives/cshare/ou1/
d--------- 2 user_ou1 пользователи домена 0 июн 17 16:00 testdir/
d--------- 2 user_ou1 пользователи домена 0 июн 17 15:55 user_ou1/

Опция cifsacl по прежнему включена
# cat /etc/auto.master.gpupdate.d/S-1-5-21-1604496143-826943209-2064588331-1114.conf | grep cifsacl
"cshare" -fstype=cifs,cruid=$USER,sec=krb5,noperm,cifsacl ://addc/share

(Ответ для Kostevich Arseniy на комментарий #16)
> >     # stat /run/media/user_ou1/drives/сshare/ou1/user_ou1/ -c %A
> После выполнения шагов вывод stat:
> d--------- 2 user_ou1 пользователи домена 0 июн 17 15:55 user_ou1/
d---------

У родительской директории /run/media/user_ou1/drives/сshare/ou1/:
drwx-----T

У нас схожая ситуация. Напрямую в смонтированной папке работать с файлами не даёт, при этом можно спокойно удалять, создавать файлы и папки. Сетевой ресурс расположен на Windows Server. Даже на сервере созданные файлы нельзя открыть из-за отсутствия прав. Никаким образом ни с Linux, ни с Windows выдать необходимые права и поменять владельца не даёт.

При этом если скопировать с локального диска файлы в сетевую папку, то права следующие:
-rw-r--r-- 1 domain_user пользователи домена 896404 июл 31 17:28 test2
----rwx--- 1 root     пользователи домена 896404 июл 31 17:36  test1

В данном случае test2 был скопирован с локального диска с Альт Линукс, а test1 - сохранённый из браузера файл сразу в смонтированную сетевую папку.

Со смонтированными вручную в Dolphin сетевыми папками проблем нет.

В /usr/share/gpupdate/templates/autofs_mountpoints.j2
если поменять параметры монтирования на эти:
-fstype=cifs,cruid=$USER,sec=krb5,rw,nounix,file_mode=0664,dir_mode=0775,iocharset=utf8

то это решает проблему с правами

В admx 0.6.0-alt1 после добавления опции отключения для пользователя проблем вроде нет уже, все нормально или вы имете ввиду вообще без опции?
Единственно при долгом простое бывает не подключаются сетевые обратно, иногда перезапуск autofs помогает, иногда приходится полностью перезагружать пк.

Включение и отключение опции cifsacl не помогало. Сейчас с включенной опцией cifsacl:
cat /etc/auto.master.gpupdate.d/S-1-5-21-.......conf

    "P" -fstype=cifs,user=$USER,cruid=$USER,sec=krb5,rw,nounix,file_mode=0664,dir_mode=0775,iocharset=utf8,cifsacl ://fileserver.domain.ru/Share

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

Благодарю за подсказку. Обновил шаблоны до 6-й версии, до этого были 5-й. Отключил опцию cifsacl и теперь нормально монтирует.

Вы на p10 или p11? admx-basealt 0.5.0-alt1 не для p10 имейте ввиду!!!

Есть и p10, и p11. На p10 это сработало, admx-basealt версии 0.6.0-alt1.

*** Bug 49992 has been marked as a duplicate of this bug. ***