Настройка файлового сервера Samba / по следам статьи в блоге

[MaximVK]

•По материалам статьи настроен файловый сервер:

Code Select Expand

[global]
   workgroup = WORKGROUP
   server string = %h server (Samba, Ubuntu)
   log file = /var/log/samba/log.%m
   max log size = 1000
   log level = 1
   server role = standalone server
   server min protocol = SMB2
   map to guest = bad user
   ntlm auth = yes

[docs]
   path = /samba/docs
   readonly = no
   guest ok = no
   vfs objects = recycle
   recycle:repository = .recycle
   recycle:versions = yes
   recycle:keeptree = yes
   hide dot files = yes

[public]
   path = /samba/public
   readonly = no
   guest ok = yes Папка /samba/docs имеет права 2770, владельцы admin и группа smbdocs (admin входит в группу)

Значение 2770 обозначает что мы предоставляем полные права владельцу и группе, для остальных доступ запрещен. А первая двойка устанавливает SGID для каталога, что обеспечивает присвоение группы каталога каждому создаваемому в нем файлу.

Я понял так, что внутри каталога все пользователи группы будут обладать всеми правами, т.е. создавать файлы и каталоги на равных. Но в действительности это не так.
Файлы и каталоги, создаются с правами по умолчанию
create mask = 0744
directory mask = 0755
Значит в подкаталог, созданный одним пользователем группы, второй пользователь этой же группы свой файл записать не сможет.
Вероятно, я неправильно понял назначение SGID? или же что-то работает неправильно? В чем практическая польза SGID в данном случае?
Следующие конфиги обеспечивают тот режим, который мне нужен:

Code Select Expand

[docs]
   path = /samba/docs
   readonly = no
   guest ok = no
   inherit permissions = yesили

Code Select Expand

[docs]
   path = /samba/docs
   readonly = no
   guest ok = no
   force directory mode = 2770
   force create mode = 760
   directory mask = 2770
   create mask = 760• Следующий вопрос по работе сетевой корзины:
папка /samba/.recycle по аналогии имет права 2770, владельцы группа smbdocs и один из пользователей группы
при recycle:keeptree = yes подкаталоги, создаваемые при удалении файла имеют права 2700, иного поведения мне добиться не удалось. (файлы же сохраняют исходные права)
Есть ли варианты добиться того, чтобы подкаталоги имели права 770? (ну чтобы другой пользователь группы мог удалить в корзину свой файл в каталоге, откуда удалил предыдущий файл другой пользователь группы)
• Для пользователей, создаваемых в статье командой useradd -M -s /sbin/nologin, вероятно, невозможно посмотреть/изменить umask ?
• Вопрос не по самой статье, но близкой тематики: В Linux нет аналогов админшары Windows (C:$)? (чтобы у пользователя не отображался общий ресурс)

[Уваров А.С.]

Я понял так, что внутри каталога все пользователи группы будут обладать всеми правами, т.е. создавать файлы и каталоги на равных. Но в действительности это не так.
Файлы и каталоги, создаются с правами по умолчанию

SGID работает не так, он делает групповым владельцем группу каталога, а не группу пользователя. А дальше все зависит от стандартного набора прав, если у вас umask 0022 - то вы получите 644 и другой пользователь сможет читать и удалять, но не сможет менять. Если стоит umask 0002 - права будут 664 и все пользователи смогут менять.

Тоже самое и с каталогами.

А дальше все зависит от того, с какой системой вы работаете и какие там umask по умолчанию. В Debian это 0022, в Ubuntu 0002 для пользователей и 0022 для root.

Затем смотрим, что именно нужно и корректируем поведение через create mask/directory mask

при recycle:keeptree = yes подкаталоги, создаваемые при удалении файла имеют права 2700, иного поведения мне добиться не удалось.

Сейчас проверил, специально создал структуру вложенных папок, права при удалении не меняются, как были 2770, так и остаются.

Для пользователей, создаваемых в статье командой useradd -M -s /sbin/nologin, вероятно, невозможно посмотреть/изменить umask ?

Нет и не надо, есть create mask/directory mask.

В Linux нет аналогов админшары Windows (C:$)?

Нет, но есть browseable = no, папка будет скрыта, но зная путь в нее можно попасть.

[MaximVK]

Спасибо за ответы!

Сейчас проверил, специально создал структуру вложенных папок, права при удалении не меняются, как были 2770, так и остаются.

То, что так должно быть, я не сомневался. Но почему у меня по-другому? Как найти причину?
В поисках ответа я установил еще на одну машину ubuntu (система та же), настроил samb-y. Теперь у меня одинаковая картина на двух реальных машинах. Значит, вероятно, что-то в моих действиях не так.
Есть ряд вопросов, ответов на которые я не знаю. Например, права 42770 (что означает 4), для файлов 100760.
Права я смотрю в mc - там удобнее. Но он как я понял работает под root (начало командной строки меняется на root), может ли это влиять, не знаю. Клиенты файлового сервера - windows 7, может NT права (файлы (каталоги) копирую и создаю из-под windows) как-то влияют...

[Уваров А.С.]

Все, я понял о чем вы. Вы о структуре папок улетевших в корзину, я думал у вас права меняются при удалении файла. Тогда, судя по документации, нужно:

recycle:directory_mode = 2770

[MaximVK]

recycle:directory_mode = 2770

Да, теперь работает правильно, большое спасибо!

[Уваров А.С.]

Вам тоже спасибо, выяснил, что упустил достаточно большой пласт при написании статьи, буду ее дополнять.

[van_dak]

Здравствуйте!
По вашим материалам поднял самбу как  отдельно стоящий файл-сервер на UBUNTU server 20.04
На предприятии сеть организована как AD с доменами на Windows Server 2012-2016. На всех клиентских машинах стоит Windows 10.
Самбы появилась как альтернатива Novell.
Вроде все хорошо, но пару моментов портят кровь.
У нас есть политика безопасности по регулярной смене пароля. Как реализовать это на Самбе(Убунту) ума не приложу.
Вопрос в следующем.
Есть ли способ реализовать периодическую смену пароля пользователя на файл-сервере не вводя при этом его в АД (домен).

Спасибо!
С уважением, Иван.

[Уваров А.С.]

Скриптом через планировщик.

[van_dak]

Можно попросить вас более подробнее объяснить. К сожалению я только начал осваивать Самбу и Убунту. Для меня многие простые вещи не очевидны.

Заранее спасибо