Cifs (samba) Разрешить доступ к разрешению (unix + zfs)

Я хочу предоставить разрешение Share для моего общего ресурса cifs, но я думаю, что unix может только предоставить разрешение файла, например:

/usr/bin/chmod -R A+group@:full_set:fd:allow pool/test 

Это плохой способ, потому что у меня есть несколько миллионов файлов в некоторых акциях, и работа заняла несколько дней! Каждый раз, когда я не хочу устанавливать каждый файл в этом каталоге.

На стороне Windows файл или папка имеют 2 разных разрешения:
1- Разрешение файла.
2. Разрешить совместное использование.

Если я использую разрешение Share, мне не нужно устанавливать chmod для каждого файла или папки в директории, вам нужно просто предоставить разрешение на использование прав доступа к каталогу Ro или Rw, чем все в порядке через несколько секунд.

Могу ли я использовать разрешение share на Solaris?

  • Надежность ZFS / ext4 на ZVOL, используемая не для производительности, а для прозрачного сжатия, в системе с низкой памятью?
  • Принудительное использование zpool / dev / disk / by-id в Ubuntu Xenial
  • FreeBSD 10: Мне нужны тюрьмы?
  • ZFS Snapshot для резервного копирования с резервным копированием
  • Почему система не реагирует, когда сетевая нагрузка составляет 90-95 Мбит / с?
  • Сочетание SSD + HDD в один быстрый, большой раздел?
  • Как заменить диск в резервном пуле ZFS?
  • Нулевая устаревшая ZFS-метка с диска с dd
  • One Solution collect form web for “Cifs (samba) Разрешить доступ к разрешению (unix + zfs)”

    Да, вы можете это сделать.

    Они хранятся в файле для каждого общего ресурса, вы можете получить доступ ( ls ) и изменить ( chmod ) этот файл в местах (при условии прямого сопоставления монтирования)

     /<pool>/<filesystem>/.zfs/shares/<share> 

    где <pool> и <filesystem> – это смонтированный путь к вашей файловой системе ZFS, а <share> – имя вашего общего ресурса CIFS. Пример:

     FS: pool0/users/bob Path: /pool0/users/bob/.zfs/shares/bobs_home 

    Но будьте осторожны: разрешения на доступ к ресурсам могут быть установлены только для всей доли, без каких-либо подразделов. Кроме того, все ACL-файлы остаются действительными и будут оцениваться. Подумайте об этом как о других воротах – после того, как вы пройдете через «общий» шлюз безопасности, вы все равно должны передать «файл» в ворота безопасности, чтобы получить доступ.

    Это зависит от ваших целей:

    • Если вы хотите предоставить различным пользователям фиксированный набор разрешений в разное время, ваш случай может быть лучше обслуживаться с использованием групп, а не пользователей в ACL файла. Вы добавляете или удаляете пользователя из группы, и он немедленно получает или теряет доступ из всех файлов, где была установлена ​​группа. Конечно, иногда вам по-прежнему приходится удалять или добавлять группу, но, скорее всего, это будет не так часто. Вы сохраняете всю детализацию.

    • Если вы хотите иметь разные «взгляды» на данные без изменения файлов вообще, даже в то же время, разрешения на доступ могут быть такими, какие вы хотите. Вы можете создать одну или несколько разделов (каждая с разными списками ACL и именами, ссылаясь на один и тот же набор данных) и быстро разрешить / запретить пользователям или группам доступ к тому, что стоит. Если пользователи могут также войти в систему локально, они могут проклинать обход этих разрешений.

    Linux и Unix - лучшая ОС в мире.