В TrueNAS была создана группа с именем "nas" и пользователь с тем же названием. Также был создан dataset под названием "share". В настройках SMB расшарена папка "test". Как настроить права доступа, чтобы пользователь "nas" мог только создавать файлы в папке "test", но не имел возможности изменять или удалять их?
В TrueNAS реализовать ограничения на уровне протокола SMB для того, чтобы пользователи могли только создавать файлы, но не могли их изменять или удалять, является достаточно сложной задачей, так как в стандартной файловой системе Unix/Linux (на базе которой построен TrueNAS) такие ограничения не поддерживаются "из коробки". Однако можно попытаться организовать подобное поведение с помощью настройки прав доступа и использования хитростей: 1. **Создание пользователей и групп**: Убедитесь, что у вас есть созданные пользователь и группа, как вы упоминали. 2. **Настройка ACL (Access Control List)**: Вам нужно настроить ACL на уровне вашего dataset. Перейдите к вашему dataset "share" и выберите его. - Зайдите в раздел "Permissions" и выберите "ACL" или "Edit Permissions". - Добавьте запись для группы "nas" с правами "Create File/Write Attributes" и "List" (чтобы они могли видеть файлы и папки), но отключите "Write" и "Delete" (чтобы они не могли их изменять или удалять). 3. **Установка umask**: Можно применить `umask`, чтобы файлы, создаваемые пользователями группы, получали более строгие права. Однако это может быть недостаточным для полной реализации, так как новые файлы будут созданны с правами доступа, которые могут позволить удаления или изменение. 4. **Использование скрипта для защиты файлов**: Можно создать скрипт, который периодически изменяет права доступа к файлам в директории "test", устанавливая их в режим только для чтения для группы "nas". Это не идеальное решение, так как потребует неких периодических действий. 5. **Настройка общей безопасности**: Подумайте об использовании более сложных решений, таких как написание скриптов, которые удаляют или изменяют права доступа после создания файлов, если вы хотите иметь более строгие ограничения. 6. **Дополнительные инструменты**: Рассмотрите возможность использования внешних инструментов или механизмов для мониторинга и контроля, чтобы предотвратить нежелательные изменения. Эти шаги помогут в создании среднего уровня контроля за файлами, но, к сожалению, полной защиты от изменений через SMB на уровне файловой системы может не существовать в стандартных условиях.
Проходили подобную блажь. Даже на NTFS, где штатные настройки прав шире, чем на *NIX-овых системах. Проведём эксперимент. Открываете со своего рабочего стола какой-нибудь *.doc или *.xls (можно *.docx или *.xlsx) жмёте "Сохранить как...", находите вашу шару с указанными ограничениями. И не можете сохранить. Почему? Это же создание нового файла на шаре? Должно работать, но не работает. Проверяем: пробуем с рабочего стола скопировать файл на шару - копируется без проблем. Ещё проверяем: пытаемся заархивировать файлы прямо на шаре, пытаемся создать на шаре бэкапы не самописным скриптом, а при помощи какого-то популярного ПО для резервного копирования. Во многих случаях обламываемся. Потому что все эти Word'ы, Excel'и, архиваторы, и куча другого прикладного ПО не подозревает о странном правиле "создавать можно, редактировать нельзя". Они сперва создают пустой файл, а потом пытаются записывать в него. В результате на шаре остаются именно пустые файлы (с правильным именем, но размером 0 байт). Создать-то пустой файл можно. Записать в него хоть что-то - это уже редактирование, это нельзя. В лучшем случае вы будете каждый день объяснять пользователям, что такие вот правила - скопировать файл Проводником (или FAR'ом, Total'ом) можно, а сохранить из большинства программ нельзя. Дополнительное действие пользователям - сначала сохранить на своём ПК, затем скопировать на шару. Пользователи, которые кидают на шару файлы не каждый день, будут забывать и каждый раз снова требовать объяснений. В худшем случае директор или главный бухгалтер в какой-то момент не только забудут, но и не заметят, что файл не сохранился, и будет скандал насчёт потери важнейшего файла.
Что касается *NIX-ообразных систем, там штатно даже и не предусмотрено разделение на "создание" и "редактирование", там это одно и то же.
Это можно решить другими методами , но выбор метода зависит от постановки исходной задачи. Например, для тех же резервных копий запрет редактирования действительно важен, но тут и хорошие варианты решения давно известны.