Я получил Ubuntu 16.04 LTS, работающий с новейшей версией Samba (2: 4.3.11 + dfsg-0ubuntu0.16.04.11).
Я настроил общий ресурс и все соответствующие разрешения unix на сами каталоги.
Моя иерархия выглядит так:
[
В каждой подпапке есть одна группа, например: Моя иерархия выглядит следующим образом: и один пользователь на группу.
Совместное использование конфигурации в smb.conf:
create mask = 6770
directory mask = 6770
force create mask = 6770
force directory mask = 6770
Таким образом, владелец и группа имеют полный доступ к этим подпапкам .
Я установил smb.conf
chmod u+s
и guid
chmod g+s
для всех этих подпапок. [ ! d15]
Итак, если я прав, каждый directoy и файл, созданный внутри этих подпапок, должны автоматически установить владельца в root и группу в улучшенную группу этой конкретной подпапки.
Он делает это для но не для владельца. Пример
Пользователь, подключенный к общему ресурсу и создающий каталог или файл, становится владельцем, несмотря на мои предыдущие настройки.
Есть ли какое-то странное поведение с unix разрешений в сочетании с samba?
Или chmod u+s просто не работает на моем дистрибутиве Ubuntu?
В соответствии с этой страницей Wiki setuid игнорируется в каталогах.
Из https://en.wikipedia.org/wiki/Setuid
setuid и setgid в каталогах [edit] Флаги setuid и setgid, установленные в каталоге, имеют совершенно другое значение. Установка разрешения setgid в каталоге («chmod g + s») создает в нем новые файлы и подкаталоги, чтобы наследовать его идентификатор группы, а не основной идентификатор группы пользователя, создавшего файл (идентификатор владельца никогда не затрагивается, только идентификатор группы). Недавно созданные подкаталоги наследуют бит setgid. Таким образом, это позволяет общему рабочему пространству для группы без неудобства требовать от членов группы явно изменять свою текущую группу перед созданием новых файлов или каталогов. влияет только на идентификатор группы новых файлов и подкаталогов, созданных после установки бита setgid, и не применяется к существующим объектам. не влияет на идентификатор группы файлов, созданных в другом месте, и перемещается в соответствующий каталог. Файл будет продолжать переносить идентификатор группы, который был выполнен, когда и где он был создан. Установка бита setgid в существующих подкаталогах должна выполняться вручную с помощью следующей команды:root@foo# find /path/to/directory -type d -exec chmod g+s '{}' \;
Разрешенные setuid-разрешения в каталоге игнорируются в системах UNIX и Linux. [4] FreeBSD можно настроить так, чтобы интерпретировать его аналогично setgid, а именно, чтобы заставить все файлы и подкаталоги владеть владельцем верхнего каталога. [5] В системах, полученных из BSD, каталоги ведут себя так, как будто их бит setgid всегда задавался независимо от его фактического значения. Как указано в open (2): «Когда создается новый файл, ему предоставляется группа каталога, которая содержит его». В соответствии с этой страницей Wiki setuid игнорируется в каталогах.
Из https://en.wikipedia.org/wiki/Setuid
setuid и setgid в каталогах [edit] Флаги setuid и setgid, установленные в каталоге, имеют совершенно другое значение. Установка разрешения setgid в каталоге («chmod g + s») создает в нем новые файлы и подкаталоги, чтобы наследовать его идентификатор группы, а не основной идентификатор группы пользователя, создавшего файл (идентификатор владельца никогда не затрагивается, только идентификатор группы). Недавно созданные подкаталоги наследуют бит setgid. Таким образом, это позволяет общему рабочему пространству для группы без неудобства требовать от членов группы явно изменять свою текущую группу перед созданием новых файлов или каталогов. влияет только на идентификатор группы новых файлов и подкаталогов, созданных после установки бита setgid, и не применяется к существующим объектам. не влияет на идентификатор группы файлов, созданных в другом месте, и перемещается в соответствующий каталог. Файл будет продолжать переносить идентификатор группы, который был выполнен, когда и где он был создан. Установка бита setgid в существующих подкаталогах должна выполняться вручную с помощью следующей команды:root@foo# find /path/to/directory -type d -exec chmod g+s '{}' \;
Разрешенные setuid-разрешения в каталоге игнорируются в системах UNIX и Linux. [4] FreeBSD можно настроить так, чтобы интерпретировать его аналогично setgid, а именно, чтобы заставить все файлы и подкаталоги владеть владельцем верхнего каталога. [5] В системах, полученных из BSD, каталоги ведут себя так, как будто их бит setgid всегда задавался независимо от его фактического значения. Как указано в open (2): «Когда создается новый файл, ему предоставляется группа каталога, которая содержит его». В соответствии с этой страницей Wiki setuid игнорируется в каталогах.
Из https://en.wikipedia.org/wiki/Setuid
setuid и setgid в каталогах [edit] Флаги setuid и setgid, установленные в каталоге, имеют совершенно другое значение. Установка разрешения setgid в каталоге («chmod g + s») создает в нем новые файлы и подкаталоги, чтобы наследовать его идентификатор группы, а не основной идентификатор группы пользователя, создавшего файл (идентификатор владельца никогда не затрагивается, только идентификатор группы). Недавно созданные подкаталоги наследуют бит setgid. Таким образом, это позволяет общему рабочему пространству для группы без неудобства требовать от членов группы явно изменять свою текущую группу перед созданием новых файлов или каталогов. влияет только на идентификатор группы новых файлов и подкаталогов, созданных после установки бита setgid, и не применяется к существующим объектам. не влияет на идентификатор группы файлов, созданных в другом месте, и перемещается в соответствующий каталог. Файл будет продолжать переносить идентификатор группы, который был выполнен, когда и где он был создан. Установка бита setgid в существующих подкаталогах должна выполняться вручную с помощью следующей команды:root@foo# find /path/to/directory -type d -exec chmod g+s '{}' \;
Разрешенные setuid-разрешения в каталоге игнорируются в системах UNIX и Linux. [4] FreeBSD можно настроить так, чтобы интерпретировать его аналогично setgid, а именно, чтобы заставить все файлы и подкаталоги владеть владельцем верхнего каталога. [5] В системах, полученных из BSD, каталоги ведут себя так, как будто их бит setgid всегда задавался независимо от его фактического значения. Как указано в open (2): «Когда создается новый файл, ему предоставляется группа каталога, которая содержит его».