Назад | Перейти на главную страницу

Безопасный метод для разрешений устройства RAID для сетевого хранилища

Я управляю небольшой сетью, которая поддерживает около дюжины сотрудников. У нас есть около 8 ТБ данных, которые хранятся на нескольких устройствах NAS. Недавно я построил файловый сервер RAID на 20 ТБ (с одним разделом XFS), и мы переходим на него.

Текущие устройства разнородны по своим разрешениям: часть хранилища - это внутренние жесткие диски, смонтированные в Windows 7; некоторые - это Drobo, подключенные к Ubuntu через USB; и пара других - это серверы Snap Server, на которых установлена ​​собственная версия UNIX.

К сожалению, сетевые рабочие станции также неоднородны. У нас есть Linux, Mac OS и Windows XP / Vista / 7/8. Это вызвало у пользователей некоторую путаницу с точки зрения разрешений. В результате, вопреки моему здравому смыслу, я в основном сделал память довольно свободной.

В этой новой системе массив монтируется в системе Linux, и все хранилище будет на этом устройстве. Таким образом, у меня есть возможность правильно его настроить с первого раза.

Здесь возникает мой вопрос. Как лучше всего это сделать? Должен ли я создавать пользователей для всех (в группе) в сети и заставлять их подключаться с этими учетными данными? Должен ли я установить разрешения на 777 и держать его открытым? Или есть лучший способ обеспечить некоторый уровень безопасности, но также упростить для моих пользователей доступ для чтения / записи к общему ресурсу?

РЕДАКТИРОВАТЬ

Из комментария я хотел бы обновить для ясности. Делюсь с Samba. И проблема, которую я вижу, - это право собственности на файлы и папки.

Например, если я создаю пользователей (в группе) на сервере, которые соответствуют учетным данным каждого пользователя на их рабочих станциях, это работает нормально для разрешений, например, каждый может получать доступ и редактировать файлы, но право собственности на файлы / папки разное. пользователь создан. Это вызывает проблему, так как общий ресурс действительно должен быть доступен для записи всем пользователям, и каждому пользователю предоставляется право удалять папки по своему усмотрению.

Какие аспекты у acls, что вам не нравится? Если вы используете все его функции (включая ACL по умолчанию для каталогов), я не могу представить себе ситуацию, с которой он не смог бы справиться. Хотя даже из-за своей сложности это немного сложно изучить и автоматизировать. Samba может даже преобразовать права доступа к объектам домена Windows в acls. Ваша проблема с правами собственности на файлы может быть решена с помощью групповых идентификаторов каталогов. Если у каталога есть setgid, вновь созданные файлы в нем будут созданы с группой каталога, а не с группой создателя.

chmod g + s / общий / каталог