Установите разрешения для корня общего ресурса (, то есть директиву SAMBA path
)на 077x
(, где x
может быть одним из 0
, 5
или 7
). и пусть SAMBA беспокоится о разрешениях. Вам нужно только смешивать разрешения файловой системы UNIX/Linux и разрешения SAMBA, если у вас есть разные способы доступа к файлам в файловой системе, соответствующей общему ресурсу SAMBA.
Если вы хотите, чтобы все ваши пользователи были одинаковыми, используйте директиву force user
. Это гарантирует, что все пользователи, обращающиеся к общему ресурсу, рассматриваются как один и тот же пользователь в файловой системе UNIX/Linux. (Это никак не связано с аутентификацией. -Пользователи по-прежнему могут аутентифицироваться с помощью отдельных учетных записей, если это то, что вы настроили.)
Вот пример общего ресурса, который делает именно это. Пользователь и группа " remote
" — это локальная учетная запись UNIX/Linux, которой будут принадлежать файлы. Группа «family
» — это набор учетных записей, которые я и моя семья используем для аутентификации в общем ресурсе.
[Family]
comment = Shared
valid users = @family
path = /home/remote/shared
vfs objects = recycle catia
browseable = Yes
read only = No
force user = remote
force group = remote
force create mask = 0664
force directory mask = 0775
Systemd не имеет жестко закодированного числового линейного упорядочения, как это было в sysv init. Он использует множество ключевых слов в юнит-файле для описания того, что запускается до, после или как часть другой службы. (См. этот ответ для более подробной информации, как указано в комментариях)
Итак, если вы хотите, чтобы iptables запускался перед другой службой, вы можете либо обновить файл сервисной единицы iptables (systemctl edit iptables.service )и добавить Before=otherservice.service, либо вы можете отредактировать otherservice. сервисный файл поставить After=iptables.service.
Модули в systemd также не выполняются последовательно, поэтому, если вы не укажете какой-либо порядок, они будут запускаться одновременно.
После загрузки системы вы можете использовать «systemd -проанализировать критическую -цепочку», чтобы лучше понять порядок, в котором все началось.