При подключении сетевых дисков через групповые политики, пользователь имеющий права на сетевой ресурс, не получает соответствующих прав, сетевые каталоги подключаются без проблем, в Групповых политиках включено Отображение сетевых дисков пользователя в домашнем каталоге, Экспериментальные групповые политики активны, после подключения к сетевому ресурсу я создаю папки, но создаются от владельца root, и после я с этой папкой не могу произвести никаких действий, предположительно проблема возникла после обновления шаблона ADMX 0.1.13.5-alt1 на версию 0.1.13.6-alt1, хотя могу и ошибаться, но до этого таких проблем не замечал. Жалко еще не работает режим нацеливания на подключение сетевых дисков конкретному подразделению или группе, подключаются все доступные шары без прав доступа правда. В инструкции хотя указано замечаниях, что Внимание! Параметр «Подключиться как» сейчас недоступен, так как в настоящее время нельзя хранить пароли в настройках групповой политики. Диск будет сопоставлен с использованием учетных данных текущей учетной записи пользователя. Но если я подключаю сетевой ресурс вручную, с указанием доменных учетных данных, никах проблем не возникает, у меня есть полные права к сетевому ресурсу. Не могу понять с чем это связано, может я что-то еще упускаю в настройках групповых политик?
Хотел бы немного добавить Версия alt-kworkstation-10.2.1 у нас уже обновилась до 10.3 Также я пробовал включать в механизмах GPUpdate Подключение сетевых каталогов и Подключение сетевых каталогов для пользователей, но без результатов.
Здравствуйте, можете пожалуйста указать версии следующих пакетов: 1. gpupdate($ rpm -q gpupdate) 2. samba($ rpm -q samba) Через какую программу происходит настройка групповых политик?(RSAT/GPUI)
Здравствуйте! rpm -q gpupdate gpupdate-0.9.13.8-alt1.noarch rpm -q samba samba-4.19.4-alt1.x86_64 Настройки произвожу непосредственно с самого Windows Server 2019 (Режим работы домена 2012 R2)
Я забыл упомянуть, что мы параллельно используем Administrative Templates (.admx) for Windows 10 May 2021, для действующих windows пользователей, может это нам проблему создает?
Created attachment 15742 [details] От доменного пользователя с root правами Не могу понять, что происходит, у пользователей которые состоят в одной и той же группе с одними же и теми правами на сетевые каталоги, создаются папки и файлы от разных владельцев, у одних как положено от доменных пользователей у других от root.
Created attachment 15743 [details] От доменного пользователя с личными правами
Очень большие проблемы с правами, хотя на windows все шикарно работает.
Здравствуйте! Не совсем понял как воспроизвести ошибку и в чем именно она заключается, поэтому запрашиваю дополнительно информацию: - Образ и ядро на котором воспроизводится ошибка (# cat /etc/os-release и # uname -a) - Конкретно расписанные все шаги воспроизведения ошибки - Ожидаемый результат - Фактический результат
(Ответ для Nikolai Zurabishvili на комментарий #9) > Здравствуйте! Не совсем понял как воспроизвести ошибку и в чем именно она > заключается, поэтому запрашиваю дополнительно информацию: > > - Образ и ядро на котором воспроизводится ошибка (# cat /etc/os-release и # > uname -a) > - Конкретно расписанные все шаги воспроизведения ошибки > - Ожидаемый результат > - Фактический результат [root@sokur-test ~]# cat /etc/os-release NAME="ALT" VERSION="10.3" ID=altlinux LOGO="basealt" VERSION_ID=10.3 PRETTY_NAME="ALT Workstation K 10.3 (Sorbaronia Mitschurinii)" ANSI_COLOR="1;33" CPE_NAME="cpe:/o:alt:kworkstation:10" BUILD_ID="ALT 10.2" ALT_BRANCH_ID="p10" HOME_URL="https://www.basealt.ru/" BUG_REPORT_URL="https://bugs.altlinux.org/" DOCUMENTATION_URL="https://docs.altlinux.org/" SUPPORT_URL="https://support.basealt.ru/" [root@sokur-test ~]# uname -a Linux sokur-test.mrsk.kbf-mrsk-sk.ru 6.1.82-un-def-alt1 #1 SMP PREEMPT_DYNAMIC Thu Mar 21 08:02:01 UTC 2024 x86_64 GNU/Linux Проблема с правами при подключении сетевых дисков с помощью групповых политик Как я писал выше у пользователей которые состоят в одной и той же группе с одними же и теми правами на сетевые каталоги, создаются папки и файлы от разных владельцев, у одних как положено от доменных пользователей у других от root(скрины я прилагал выше). Я предположил, что проблема с липким битом, его снятие тоже не помогло. Доменные пользователи у которых создаются папки на сетевом ресурсе с владельцем от имени root нет никаких прав, а доменные пользователи, от которых папки создались корректно т.е. владельцем является он сам, предварительно нужно дать права, что внутри созданного каталога выполнять какие либо действия. Если сетевой ресурс подключается через smb://fileserver/share (с указанием учетных данных после запроса), на все папки и файлы есть полные права для всех пользователей. Я бы лучше наглядно продемонстрировал всю картину, только не знаю как, может я не очень ясно излагаю происходящее.
(Ответ для Murat на комментарий #10) > (Ответ для Nikolai Zurabishvili на комментарий #9) > > Здравствуйте! Не совсем понял как воспроизвести ошибку и в чем именно она > > заключается, поэтому запрашиваю дополнительно информацию: > > > > - Образ и ядро на котором воспроизводится ошибка (# cat /etc/os-release и # > > uname -a) > > - Конкретно расписанные все шаги воспроизведения ошибки > > - Ожидаемый результат > > - Фактический результат > [root@sokur-test ~]# cat /etc/os-release > NAME="ALT" > VERSION="10.3" > ID=altlinux > LOGO="basealt" > VERSION_ID=10.3 > PRETTY_NAME="ALT Workstation K 10.3 (Sorbaronia Mitschurinii)" > ANSI_COLOR="1;33" > CPE_NAME="cpe:/o:alt:kworkstation:10" > BUILD_ID="ALT 10.2" > ALT_BRANCH_ID="p10" > HOME_URL="https://www.basealt.ru/" > BUG_REPORT_URL="https://bugs.altlinux.org/" > DOCUMENTATION_URL="https://docs.altlinux.org/" > SUPPORT_URL="https://support.basealt.ru/" > [root@sokur-test ~]# uname -a > Linux sokur-test.mrsk.kbf-mrsk-sk.ru 6.1.82-un-def-alt1 #1 SMP > PREEMPT_DYNAMIC Thu Mar 21 08:02:01 UTC 2024 x86_64 GNU/Linux > > Проблема с правами при подключении сетевых дисков с помощью групповых политик > Как я писал выше у пользователей которые состоят в одной и той же группе с > одними же и теми правами на сетевые каталоги, создаются папки и файлы от > разных владельцев, у одних как положено от доменных пользователей у других > от root(скрины я прилагал выше). > Я предположил, что проблема с липким битом, его снятие тоже не помогло. > Доменные пользователи у которых создаются папки на сетевом ресурсе с > владельцем от имени root нет никаких прав, а доменные пользователи, от > которых папки создались корректно т.е. владельцем является он сам, > предварительно нужно дать права, что внутри созданного каталога выполнять > какие либо действия. > Если сетевой ресурс подключается через smb://fileserver/share (с указанием > учетных данных после запроса), на все папки и файлы есть полные права для > всех пользователей. > Я бы лучше наглядно продемонстрировал всю картину, только не знаю как, может > я не очень ясно излагаю происходящее. Чтобы воспроизвести ошибку мне нужны конкретные шаги, действия, которые к ней приводят. Потому что так я не понимаю, как конкретно, кем создавать папки/файлы после добавления сетевого диска через групповые политики. Можете записать видео воспроизведения ошибки с тестовыми папками/файлами если будет удобнее для наглядности
Будет возможность организовать видео связь через какой ни будь мессенджер?
Пожалуйста, напишите конкретно, какие политики и как именно вы настраиваете. По шагам. Так же можете приложить скриншоты.
Или, если есть возможность, обратитесь в техподдержку.
Created attachment 15754 [details] Используемые настройки GPO для ALT При подключении пользовался следующей инструкцией https://www.altlinux.org/Групповые_политики/Подключение_сетевых_дисков, в формате excel прикладываю настройки gpo для alt. К сожалению групповые политики не входят перечень услуг, которую закупила организация.
(Ответ для Murat на комментарий #15) > Создано вложение 15754 [details] [подробности] > Используемые настройки GPO для ALT > > При подключении пользовался следующей инструкцией > https://www.altlinux.org/Групповые_политики/Подключение_сетевых_дисков, в > формате excel прикладываю настройки gpo для alt. > К сожалению групповые политики не входят перечень услуг, которую закупила > организация. Шаги воспроизведения (из : 1) На клиенте в GPUI/RSAT включить поддержку экспериментальных групповых политик и механизм подключения сетевых каталогов: Компьютер -> Административные шаблоны -> Групповые политики -> Экспериментальные групповые политики -> Включено Компьютер -> Административные шаблоны -> Групповые политики -> Механизмы GPUpdate -> Подключение сетевых каталогов для пользователей -> Включено Пользователь - Административные шаблоны -> Система ALT -> Монтирование -> Отображение сетевых дисков машины в домашнем каталоге -> Включено Пользователь - Административные шаблоны -> Система ALT -> Монтирование -> Отображение сетевых дисков пользователя в домашнем каталоге -> Включено 2) В GPUI/RSAT открыть раздел Пользователь - Настройки - Настройки системы - Сетевые диски ПКМ на пустом поле справа - Новый - Сетевой диск 3) Настроить диск: Действие: Создать Путь: \\dc\share Включить чекбокс "Переподключиться" Название: "user-share" Включить чекбокс Первый доступный, начиная с А Нажать OK 4) Перезагрузить клиентскую систему, авторизоваться доменным пользователем На рабочем столе (на системе с KDE в домашней папке) появился сетевой диск с именем drives, в котором находится папка с именем user-share Уточните дальнейшие шаги для воспроизведения ошибки и ожидаемый, а также фактический результат
Возможно проблема с правами сетевых каталогов связана с https://bugzilla.altlinux.org/show_bug.cgi?id=49030#c4
Created attachment 15755 [details] Права на каталог Все именно как вы расписываете, на примере 2х пользователей с абсолютно идентичными правами, к примеру под собой и под одним тестовым пользователем, когда я захожу под собой, у меня все папки и файлы создаются от владельца root, даже созданные на рабочем файлы владельцем которых являюсь я при перемещении в файлообменник владелец тоже меняется на root, захожу под тестовым пользователем, у него в обменнике создаются папки и файлы от своего имени, он может их удалять, но чтобы создать внутри созданной им папки что-то, необходимо предварительно на свою же папку дать права, а именно для владельца "Просмотр и изменение содержимого" и "Применить изменения ко всем вложенным папкам и их содержимому", если он для "Применить изменения ко всем вложенным папкам и их содержимому" не проставит одновременно галочку и нажмет ок, и он уже не может больше произвести никаких манипуляций с данной папкой. Из под windows все шикарно работает со всеми правами. Но если я подключаюсь через smb://<server_IP>/ushare, указываю учетные данные в формате domain\user и пароль, у меня полные права на все папки и файлы и там нет никаких владельцев и прав (прикладываю еще один скрин) в отличие при подключении через gpo. Шара на Windows у меня если забыл упомянуть. Как писал выше, удаление липкого бита тоже не помогло до удаления drwxr-x--t 2 root domain users 8192 мар 22 16:49 Obshchiy_obmen после удаления drwxr-x--- 2 root domain users 8192 мар 22 16:49 Obshchiy_obmen
(Ответ для Murat на комментарий #18) > Создано вложение 15755 [details] [подробности] > Права на каталог > > Все именно как вы расписываете, на примере 2х пользователей с абсолютно > идентичными правами, к примеру под собой и под одним тестовым пользователем, > когда я захожу под собой, у меня все папки и файлы создаются от владельца > root, даже созданные на рабочем файлы владельцем которых являюсь я при > перемещении в файлообменник владелец тоже меняется на root, захожу под > тестовым пользователем, у него в обменнике создаются папки и файлы от своего > имени, он может их удалять, но чтобы создать внутри созданной им папки > что-то, необходимо предварительно на свою же папку дать права, а именно для > владельца "Просмотр и изменение содержимого" и "Применить изменения ко всем > вложенным папкам и их содержимому", если он для "Применить изменения ко всем > вложенным папкам и их содержимому" не проставит одновременно галочку и > нажмет ок, и он уже не может больше произвести никаких манипуляций с данной > папкой. Из под windows все шикарно работает со всеми правами. Но если я > подключаюсь через smb://<server_IP>/ushare, указываю учетные данные в > формате domain\user и пароль, у меня полные права на все папки и файлы и там > нет никаких владельцев и прав (прикладываю еще один скрин) в отличие при > подключении через gpo. Шара на Windows у меня если забыл упомянуть. Как > писал выше, удаление липкого бита тоже не помогло > до удаления > drwxr-x--t 2 root domain users 8192 мар 22 16:49 Obshchiy_obmen > после удаления > drwxr-x--- 2 root domain users 8192 мар 22 16:49 Obshchiy_obmen Возможно дело именно в файловом менеджере kde dolphin из KWorkstation 10.2.1 x86-64 Попробуйте повторить ваши действия на системах с mate например Workstation 10.1 x86-64 и посмотреть проявляется ли проблема аналогично
А как тогда объяснить подключение вручную через адресную строку smb://<server_IP>/ushare, может схема авторизации отличается? Наши коллеги из другого филиала сказали, что mate не поддерживает 2 монитора, они отказались от него, сам не проверял.
Не удалось воспроизвести ошибку
Я уже права со всех папок удалил и обратно вернул, пробовал на одну отдельную папку, проблема сохраняется. Может по каким-то логам можно посмотреть? Реально аномальная картина.
(Ответ для Murat на комментарий #22) > Я уже права со всех папок удалил и обратно вернул, пробовал на одну > отдельную папку, проблема сохраняется. Может по каким-то логам можно > посмотреть? Реально аномальная картина. Можно посмотреть логи gpupdate.log и gpoa.log # gpupdate &> gpupdate.log && gpoa --loglevel 0 &> gpoa.log В p10 скоро выйдет новая версия gpupdate-0.9.13.9-alt1, попробуйте потом посмотреть на ней сохранится ли данная проблема
Добрый день! В данной версии gpupdate-0.9.13.9-alt1 мне обещали, что поправят проблему с прокси. У нас произошло следующее, адрес прокси прописывали в соответствии с инструкцией https://www.altlinux.org/Групповые_политики/Прокси-сервер в формате: HTTP_PROXY=http://10.0.66.52:3128 HTTPS_PROXY=http://10.0.66.52:3128 После обновления шаблона как писал выше, у всех пользователей альт пропал Интернет, при проверке обнаружили, что настройки приходят без одного «/» $ env |grep HTTP HTTP_PROXY=http:/10.0.66.52:3128 HTTPS_PROXY=http:/10.0.66.52:3128 Прописали настройки в следующем формате HTTP_PROXY=10.0.66.52:3128 HTTPS_PROXY=10.0.66.52:3128 Так заработало. В логах я сам ничего не увижу, нужно наверное чтобы разработчик посмотрел. У меня 3 контроллера домена, 2 из них на 2019 и один на 2012r2, еще с 2 я доменами доверительные отношения, еще права на папку выданы группам в группе, не знаю, может что-то из этого и создает проблему, хотя на винде все шикарно работает при этом.
Created attachment 15770 [details] gpupdate.log В версии gpupdate-0.9.13.9-alt1 как и обещали проблему с прокси исправили, проблемы с сетевыми дисками остались, логи прилагаю.
Доброго времени суток, наконец-то разобрался, почему на сетевом файловом сервере файлы и каталоги создавались от владельца root, оказалось, что данном сервере присутствовала моя учетная запись с правами администратора, после удаления данной учетки файлы и каталоги начали создаваться от моего имени, но работы внутри каталогов необходимо предварительно выдавать права, в примечаниях в документации указано, что "Внимание! Параметр «Подключиться как» сейчас недоступен, так как в настоящее время нельзя хранить пароли в настройках групповой политики. Диск будет сопоставлен с использованием учетных данных текущей учетной записи пользователя." Наверное это и имеется ввиду. Спасибо всем за отклики!!!
