Небольшой мануал по настройке самбы и прав доступа к файлам/каталогам в
XIGMANAS. Написал по причине того что мне это потребовалось, а обобщенной информации на просторах не нашел…
В общем, ниже будет описание пары пунктов в интерфейсе «Сигмы» и применение chown/chmod через консольку. Человеку, хоть немного щупавшему линуксы, далее будет не интересно, но собрать в кучу информацию по настройке всего этого дела для последующего использования неподготовленным новичком — думаю всё же стоит (мне бы такое точно пригодилось).
Итак,
NAS собранный в предыдущем обзоре работает, проблем не вызывает и я о нем даже начинаю забывать. Что с одной стороны хорошо, с другой нужно какую-нибудь напоминалку для выполнения
scrub хотя-бы раз в год сделать что-ли…
Но вернемся к самбе и правам доступа: по умолчанию в расшаренных каталогах всё разрешено всем, точнее, при любом подключении используется единственный пользователь, который и является полноправным владельцем всего. И вот, давненько уже, возникла потребность разграничения доступа, поскольку в домашней сети начали появляться не только «домашние» компьютеры. Хотелось сохранить простой, безпарольный доступ к имеющемуся кладезю развлекательной и прикладной информации, ограничив при этом возможность удаления и закрыв доступ к «конфиденциальным» файлам. Например, иногда антивирусы не-подконтрольных мне компьютеров удаляют те файлы, которые у меня везде добавлены в доверенные списки (в первых рядах это, естественно, KMSauto), а узнаю я об этом позже, когда они мне срочно необходимы.
В процессе настройки потребуется: WEB-интерфейс и консоль для подключения к серверу по ssh (я использую широко-известную
PuTTY, причем для подключения к xigmanas версии 12 и выше нужно использовать как минимум
release 0.78, иначе при попытке подключения будет возникать ошибка). Кроме этого, желательно, хотя-бы примерно представлять что требуется разрешить/ограничить, а так-же сколько и какие пользователи должны быть в системе.
О правах доступа к файлам в Linux
Про права доступа в Linux подробно можно прочитать огромное количество информации по первым ссылкам запроса в гугле, наиболее просто и понятно мне показалось
здесь.
Своими словами могу упростить так: любому файлу и каталогу соответствуют 3 типа разрешений для каждого из 3-х «типов доступа».
- Разрешения: r-чтение; w-изменение/удаление; x-выполнение.
- Доступ для: Owner — пользователь владелец/создатель файла или каталога; Group — группа владелец/создатель файла или каталога (это может быть любая группа, даже отличная от группы пользователя создавшего файл); Public — доступ всех остальных пользователей (не владельцы и не состоящие в группе).
Увидеть разрешения можно через WEB-интерфейс, однако там не отображаются имена пользователя и группы, что немного неудобно.
В меню выбираем Tools/File Manager и в таблице файловой системы в столбце Permissions видим аббревиатуру прав доступа для всех типов в одну строку:
При клике они раскрываются в детальном виде, где права можно изменить:
Но изменения применяются только для выбранного объекта, если это каталог, то права вложенных объектов не изменятся.
Для удобства буду опираться на свои планы и требования, итак.
Пользователи: Пользователей будет по количеству членов семьи и один общий пользователь для подключения к шарам без пароля (по умолчанию самба использует системного пользователя ftp — заменим его), групп доступа нужно две — для общего пользователя и «семья» (для домашнего использования врядли потребуется больше).
Каталоги: Есть общий каталог с документами, в котором располагаются личные каталоги пользователей и личный семейный каталог, есть каталог с медийкой и софтом, есть торрент и так называемый «общак» доступный абсолютно всем.
Правила: Доступ в документы должен быть у всех на чтение (фоточки посмотреть или еще что), личные каталоги в документах доступны только пользователям группы семья и только для чтения, полный доступ имеется у владельца (внутри можно даже сделать каталог недоступный никому кроме владельца). На торрент и «общак» права не ограничиваем никому, а каталог с хламом и софтом всем доступен для чтения и разрешение изменений у пользователей группы «семья».
Прежде создаем группы и пользователей. Делать это нужно из web-интерфейса, для того чтобы пользователи сохранялись в конфигах и не было проблем при апдейтах переносах.
(Если создать их из консоли через pw — они также будут видны в интерфейсе, их можно будет использовать в настройках, но, как заметили в комментах — это может вызвать проблемы при переносе конфиги на новое железо и т.п. Это не точно, но лучше будет, как я и писал изначально — создать пользователей и группы в интерфейсе).
Создание групп и пользователей в XigmaNAS
В меню интерфейса выбираем
Access/Users&Groups далее переключаемся на вкладку
Groups и жмакаем внизу страницы кнопку
+ «Добавить».
На странице добавления группы пишем название группы (без пробелов) и описание (любое), Group ID не меняем.
Нажимаем
Add (Добавить) и повторяем — создаем вторую группу family.
Далее применяем сделанные изменения, жмем
Apply changes.
Переключаемся на вкладку Users и создаем пользователей (так-же жмакаем плюсик внизу страницы).
Создаем общего пользователя для использования в сетевом доступе для всех:
Здесь заполняем
Login Name,
Full Name, задаем пароль (его не потребуется сообщать никому),
User ID не меняем,
Shell — оставлем No login,
Home directory изменяем на "/home",
Primary Group — выбираем созданную ранее группу для пользователей самбы. Остальное оставляем как есть. Создаем пользователя (
Add).
Аналогичным образом создаем остальных персональных пользователей (для каждого члена семьи то-есть), для них используем те же параметры, за небольшими изменениями. Во первых пароль и логин потребуются при последующих авторизациях пользователя и их лучше заранее согласовать (причем пароль можно будет изменить после в любое время, но логин останется как есть).
При создании пользователей указываем в
Primary Group — группу family, и в
Groups — отмечаем чекбоксом группу общую для подключающихся пользователей (это smb_guests у меня, например), т.е. создаваемые пользователи принадлежат основной группе family, но так-же входят и в группу smb_guests (набор групп можно будет менять и после создания). Это нужно для дальнейшей настройки прав доступа, если пользователь входит в какую-либо группу, все привилегии группы — также распространяются на него.
На этом создание пользователей и групп завершено.
Далее проверяем и дополняем настройки самбы (SMB), основные настройки уже описывал в
предыдущем обзоре, сейчас их немного меняем.
Переходим в web-интерфейсе в меню
Services>SMB>Settings, жмем внизу страницы
Edit.
Здесь нас интересует раздел Advanced SMB Settings.
1.
Guest Account — выбираем общего пользователя, который был создан для подключений. Этот пользователь будет использоваться в качестве «Гостя».
2.
Map to Guest — оставляем "
Bad User- (Non Existing Users)". Т.е. этот параметр определяет кого считать гостем, при выбранном варианте «Гостем» будет назначен вообще любой пользователь который не смог авторизоваться или не авторизовывался (с пустым логином и паролем). Если выбрать в меню "
Never — (Default)", то «Гостем» автоматически никто не назначается, то-есть нужно будет обязательно вводить правильный логин/пароль при подключении к сетевой папке.
3,4.
Force User/Group — здесь задается принудительное переключение пользователя или группы, в которую пользователь входит. Т.е. выбрав здесь какой-либо вариант в меню — зашедший в сетевую папку пользователь будет всегда переопределен на выбранный вариант — не важно ввел ли он корректный логин/пароль или нет. Для моих требований данный параметр не нужен — оставляю
Default.
Переходим на вкладку
Shares, здесь создаем «шару» или проверяем/меняем параметры существующей.
1.
Guest — разрешаем использование «Гостевого» пользователя, того что настраивался выше, в advanced параметрах SMB.
2,3. —
Force User/Group — принудительное переключение пользователя или группы, но уже для конкретной шары, в каких то случаях это может понадобится, но мне сейчас не нужно —
Default.
4.
Inherit Permissions — Наследование прав доступа родительского каталога, если чекбокс снять — новые файлы и каталоги будут создаваться с правами по умолчанию, т.е. всё всем разрешено (если не настроено другого).
5.
Inherit ACL — Наследование списков контроля доступа — ACL (это дополнительные разрешения, которые можно независимо раздавать нескольким пользователям\группам а не только владельцам). Провел тесты включая/отключая этот чекбокс — наследования я не увидел, ни для отдельных пользователей, ни владельцев (ACL), чтож, может я что то делал не так — пусть, на всякий случай, будет включен.
Подготовительные этапы завершены, переходим, собственно, к раздаче прав доступа.
Берем консоль, подключаемся к nas и переходим в интересующий каталог, (все созданные ранее пулы и датасеты расположены в /mnt/).
(В комментах были возражения, что все манипуляции нужно делать в интерфейсе, однако раздача прав из интерфейса сильно урезана в текущей версии XigmaNAS и использование консоли для указанных действий оправдано. Повторюсь — эти действия не приведут к каким-либо проблемам с последующими переносами/обновлениями системы.)
Использование консоли на примере PuTTY
Запускаем PuTTY и вводим ip адрес сервера в строку, порт оставляем 22. Жмём
Open.
В открывшемся окне/консоли вводим логин\пароль администратора (которого создали при установке Xigmanas) или root пользователя (обычно это один и тот же пользователь).
Чтобы перемещаться по каталогам и смотреть что в этих каталогах находится используем две команды —
cd и
ls. При подключении мы оказываемся в каталоге того пользователя, под которым подключились, на данный момент это root, его домашний каталог обозначается значком
~ в строке ввода команд. Просмотр содержимого в этом каталоге (пишем ls и жмем enter) выведет следующее:
Для перехода в какой либо каталог, нужно ввести в консоли:
cd <полный путь к каталогу>.
Например переход в созданный мною ранее датасет выполняем так: cd /mnt/testpool/testdataset/
Далее команда ls выводит содержимое текущего каталога (содержимое на скрине написано синим цветом).
Чтобы вернуться «Назад» в каталог уровнем выше — используем:
cd ..
Чтобы перейти в какой либо каталог, который располагается в текущем каталоге:
cd ./catalog_name/
Пример:
Чтобы увидеть содержимое каталога с отображением владельцев и разрешений используется команда:
ls -l
Выводится следующая информация:
1. Собственно права доступа, rwx — чтение/изменение/выповлнение, для владельца/группы/остальных.
2. Пользователь владелец файла или каталога.
3. Группа владелец файла или каталога.
4. Название файла каталога.
Вообще, для просмотра структууры/расположения каталогов и файлов удобнее пользоваться web-интерфейсом и уже определившись с тем что нужно по нему — вводить команды в консоли. Напомню что в интерфейсе это:
Tools > File Manager. И здесь всегда указан путь к текущему каталогу.
Поскольку ранее в настройках было указано наследование прав доступа, то задав права «корневым»/расшаренным каталогам — эти права будут распространятся на все новые файлы/каталоги, создаваемые сетевыми пользователями.
Итак, задаем права и владельца всем тем каталогам, которые непосредственно расшарены и, на всякий случай (если они не пустые), используем параметр рекурсии, чтобы используемые права применились для всех файлов/каталогов внутри. 1. Переходим в каталог. 2. Задаем владельца пользователя для каталога. 3. Задаем владельца группу для каталога. 4. Задаем права доступа.
1# cd /mnt/testpool/testdataset/
2# chown -R <пользователь> <каталог>
3# chgrp -R <группа> <каталог>
4# chmod -R ugo=rwx <каталог>
Подробнее о командах
В моем примере я использую команды:
1# cd /mnt/testpool/testdataset/
2# chown -R smb_guest Documents
3# chgrp -R smb_guests Documents
4# chmod -R ugo=rwx Documents
Результат:
Здесь команда "
chown -R smb_guest Documents" обозначает:
chown — сама команда, это сокращение от change owner;
-R — это параметр применения рекурсии, т.е. действие команды распространяется на все вложенные файлы и каталоги;
smb_guest — логин нового владельца;
Documents — название каталога (или файла, к которому применяется команда), нужно помнить, что в линуксах Регистр названий имеет значение, т.е. нужно соблюдать написание заглавных и прописных букв, а также здесь пробелы в именах файлов нужно «экранировать» обратным слэшем, т.е. название каталога «Мои документы» нужно будет записать так «Мои\ документы».
Команда "
chgrp -R smb_guests Documents" обозначает:
chgrp — сама команда, это сокращение от change group;
-R — рекурсия;
smb_guests — новая группа владелец;
Documents — название каталога (или файла, к которому применяется команда), особенности написания те-же.
Команда "
chmod -R ugo=rwx Documents" обозначает:
chmod — сама команда, это сокращение от change mode;
-R — рекурсия;
ugo — параметр, для кого применяется правило, т.е. u — user (владелец файла), g — group (группа, которой принадлежит файл), o — other (остальные пользователи) — эти параметры можно комбинировать, использовать только те что требуются;
rwx — применяемые разрешения, для указанных «типов владельцев», т.е. это именно разрешения, если не указать какое либо разрешение из rwx — то оно будет запрещено (если не указать ничего — то всё запрещается);
Documents — название каталога (или файла, к которому применяется команда), особенности написания те-же.
Я применил все возможные разрешения для общего пользователя, мне такой вариант приемлем, потому что далее я буду задавать другие права уже вложенным каталогам и файлам.
Сейчас всем каталогам и их содержимому назначен владельцем общий пользователь и даны максимальные разрешения:
Переходим к детальным ограничениям (каталоги с торрентами и общаком далее не трогаем — для них все параметры уже корректны).
Каталог
Sklad. Здесь лежат музыка/видео и дистрибутивы программ, вобщем всё что нажито с начала времен, т.е. с 1 января 1970 года (это шутка, если что, я не такой старый). Требуется разрешить чтение всем, но изменение только пользователям группы family. Для этого: 1. переходим в родительский каталог, если мы не находимся в нем; 2. меняем группу-владельца каталога (с содержимым); 3. владельцу и прочим разрешаем только чтение+выполнение (группа остается с полным доступом).
1# cd /mnt/testpool/testdataset/
2# chgrp -R family Sklad
3# chmod -R uo=rx Sklad
Конечно можно было использовать эти параметры при первоначальном назначении разрешений, описанных выше, но для примера, мне кажется, текущий вариант лучше.
Поскольку у нас в параметрах стоит наследование прав и разрешений, после таких настроек любой созданный в каталоге файл будет иметь те-же разрешения, что и родительский каталог, а так-же наследовать «группу владельца» от родительского каталога. Поэтому не важен пользователь создавший файл в каталоге (он будет владельцем но группа для файла будет применена от родительского каталога) — у пользователя будет только право чтения, а разрешение на удаление/изменение будет регулироваться группой, в которую пользователь входит.
Каталог
Documents. Внутри личные и общие каталоги (общие для чтения). Требуется разрешить чтение общих каталогов всем, чтение личных каталогов членам группы family, но изменение только пользователям которым каталоги принадлежат, ограничить доступ к общим семейным каталогам. Для этого: 1. переходим в родительский каталог, если мы не находимся в нем; 2. изменяем группу каталога на family; 3. рекурсивно всем всё запрещаем полностью (далее уже не будем изменять права «остальным» — они так и останутся полностью запрещенными); 4. разрешение пользователю и группе без рекурсии (это общий пользователь и группа family) на текущий каталог чтение+выполнение пользователю и полный доступ группе; 5. переходим в каталог; 6. изменяем владельца личных каталогов (на примере одного); 7. изменяем разрешения личных каталогов, группе только чтение, владельцу полный доступ; 8. изменяем разрешения общих каталогов, остальным и владельцу только чтение, группе полный доступ; 9. изменяем разрешения общих семейных каталогов, группе полный доступ (пользователь и остальные остаются без доступа).
1# cd /mnt/testpool/testdataset/
2# chgrp -R family Documents
3# chmod -R ugo= Documents
4# chmod u=rx Documents
4# chmod g=rwx Documents
5# cd ./Documents/
6# chown -R father Doc\ father
7# chmod -R u=rwx Doc\ father
7# chmod -R g=rx Doc\ father
8# chmod -R uo=rx foto
8# chmod -R g=rwx foto
9# chmod -R g=rwx scans
В итоге каталог
Documents может прочитать как общий пользователь, так и члены группы family, но внутри все каталоги имеют индивидуальные разрешения. И при создании нового каталога в Documents, он будет наследовать разрешения родительского (полный доступ группы + чтение пользователем) и группу родительского (это family), т.о. создавать что то могут только пользователи группы family и любые новые файлы/каталоги в Documents не будут доступны общему пользователю без дополнительных специальных разрешений на это.
Чтож, владельцы и группы назначены, далее права доступа, на существующие объекты можно задавать из web-интерфейса. Например, сделаем каталог в личных документах доступным только лично пользователю и недоступным никому другому (кроме root конечно))).
Переходим в меню
Tools > File Manager далее находим интересуемый каталог (в моем примере это
closed), кликаем на разрешения в
Permissions и снимаем чекбоксы со всех кроме владельца (Owner). Нажимаем Change. Готово! Доступ к каталогу
closed теперь только у пользователя father.
Переходим к конфигурации доступа к расшаренным и настроенным каталогам из Windows.
При первом обращении к расшаренному каталогу в Windows возможны 2 варианта: будет запрошен логин\пароль с возможностью сохранить его или автоматически будет использован другой профиль (сохраненый ранее или гостевой).
В случае, если запрашиваются аутентификационные данные — вводим корректные логин/пароль и отмечаем чекбокс сохранения (или нет, по желанию).
Проверка пользователя
В целом пользователя можно определить, попыткой получить доступ к личному каталогу, но если такогого нет — заходим в обущю шару и создаем там файл. Далее через консоль (
ls -l )смотрим какой пользователь является его владельцем.
Это нужно проверять по причине того, что используемые настройки сервиса SMB, при некорректном вводе логина/пароля — переключат некорректного пользователя на «Гостя» автоматически, без сообщения об ошибке.
Если происходит открытие сетевой папки без запроса пароля и пользователь не тот что требуется, то нужно сбросить текущие используемые учетные данные и принудительно задать корректные (тут я не смог выяснить достоверно, из-за чего винда может запрашивать аутентификацию, а из-за чего нет… тестировал на двух примерно одинаковых системах, без сохраненных учетных данных — и на одном компе при открытии новой шары всегда запрашивается пароль, но на другом компе этого не происходит никогда — всегда выполняется автоматический вход гостем).
Для изменения/добавления учетных данных:
Очищаем кэшированные данные, для сетевых каталогов если они есть (это требуется не всегда, можно пропустить этот пункт и после добавления\изменения учетных данных перезагрузить компьютер). Для этого закрываем все открытые проводником сетевые папки, запускаем командную строку и выполняем команду:
net use
В открывшемся списке находим всё что связано с нашим сервером и удаляем командой
net use <каталог> /del
Далее открываем «Панель управления» и в ней «Диспетчер учетных данных», выбираем раздел «Учетные данные Windows» (либо сразу «Диспетчер учетных данных» поиском в Windows 10).
Далее в разделе "
Учетные данные Windows" находим существующие данные для нашего сервера, определяем его по ip адресу или сетевому имени (netbios name). Раскрываем и нажимаем «Изменить» — указываем нужные логин/пароль (пользователь так-же может присутствовать в разделе «Общие учетные данные» — в этом случае просто удаляем его).
Если учетные данные для нашего сервера отсутствуют, нажимаем пункт «Добавить учетные данные Windows» и заполняем:
После этого, скорее всего потребуется перезагрузится (у меня при тестировании чаще всего перезагрузка требовалась, но не всегда).
Теперь заходим в сетевые папки и проверяем корректность введенных данных. Сейчас будут доступны каталоги разрешенные пользователю и при попытках зайти в чужой личный каталог, либо создать файл в каталоге без разрешения — будет возникать ошибка.
На этом настройки можно считать завершенными. В Windows заданы аутентификационные данные для сетевого ресурса (и если они сохранены — то не будут запрашиваться при последующих обращениях к этому серверу), а на сервере назначены права группам и пользователям.
Подключение сетевого диска
Расшаренные каталоги можно подключить как сетевые диски, но если задан пользователь для подключения к сетевому ресурсу, как указано выше — то использовать другой логин/пароль не получится, потребуется использовать существующий профиль.
Для подключения сетевого диска: Отрываем «Мой компьютер», в меню выбираем «Компьютер» и «Подключить сетевой диск».
Выбираем букву диска и указываем сетевой каталог, который хотим подключить, чекбокс «Использовать другие учетные данные» оставляем снятым.
Готово!
Выглядит заманчиво, однако, как сообщает нам вики — FreeBSD этот функционал самостоятельно не поддерживает, только, каким-то образом, силами самой ZFS, причем, как я понял в не особо распространенном формате.
Немного потестил это наследование на виртуалке, и, опять же, результата не увидел… Права назнаются и отдельным пользователям и группам на родительские каталоги, но дочерним они не передаются. Предполагаю, что для полноценного функционирования ACL нужно еще что-то дополнительно включить или доустановить — мне в этом сложно разобраться. Вобщем вопрос серьезный, но для меня не особо важный — весь требуемый функционал реализцется стандартными правами с запасом, так что на этом пожалуй закончу.
У людей весьма особенные представления о «Сделано руками».
Или уже поменяли?
для подобного рода материалов не так уж много места для публикаций
и атмосфера не везде способствует
а нужда есть, мало кому что есть — вон более 30 человек уже залайкали значит есть кому это читать здесь
Тоже бывает смотришь на «обзор» и думаешь — «Ну явно тема не к месту, уж я то такого никогда не сделаю!»
И вот результат ))))))
Ну в общем глянул я скриншоты, все что вы сделали рукми можно было без проблем настроить в веб морде. Зачем все это было городить не понятно.
Всё что можно сделать в интерфейсе — я сделал в интерфейсе, то что в интерфейсе сделать нельзя — я написал как это нужно делать через консоль. Однако, если всё настраивать «с нуля» — можно разрешения rwx покликать через интерфейс; если в каталогах уже есть данные — то накликать их нереально — только консоль и команды с рекурсией.
И опять — Если делать как я написал, то каждый апдейт оболочки не будет ни на что влиять.
Одной этой фразы достаточно чтобы понять что вы не знаете что вы делаете.
Вот вам описание:
inherit acl — включает режим наследования ACL от каталога, в котором создаются новые файлы и каталоги. Без этого параметра дополнительные ACL не будут наследоваться для новых файлов, будут наследоваться только unix mode разрешения.
ну и если взять абстрактную ситуацию — сделать рабочую шару в сети с компами на XP и win10 без включения SMB нереально
Включая самбу первых версий, ты включаешь ее на ноутбуке для всех сетей, помеченых как не «public».
с одним HDD оно правда не особо интересно
а вот когда самосборка в большом корпусе то вопрос добавления дисков становиться интереснее
а уж в готовой то оболочке такое по умолчанию должно быть
АНЕКДОТ
1) Не вполне понятна исходная задача. Я понимаю если в конторе мелкой. Что такого есть в семье, что нельзя показать маме и деткам но можно папе. Разве что прон. Вроде проще можно решить задачу?
2) Мама-дети не способны получить root доступ? Бекапы конфига шифруете?
3) Если мама скачала файлы (годовую подписку на журнал по вязанию) из сети торрентом и положила всю папку к себе — что будет с правами? Они станут автоматически как у всех? Будет солянка? И как лечить?
Ну и скорее совет — Shadow copy через снимки настраивали? Производит волшебное впечатление на людей. Я описывал (да, я тот 2gusia, спасибо за упоминание в 1 статье — тогда не читал, личные траблы были.)
ну а тем более если это скажем обзор местных борделей :)
PS: начиная с DSM7, умеет бэкапить образы NAS Synology целиком на другой сино. Со всеми потрохами, включая системный раздел.
и имеет web интерфейс для дистанционной настройки
впрочем как и большинство аналогичных программ
в состав таких комбайнов, описанных она тоже может либо поставиться либо addon/plugin, но, в общем то ее прекрасно можно использовать и на «голом» сервере
так что готового решения у меня нет, но в планах разобраться как оно сейчас. Начинал бы с двух упомянутых софтин.
www.resilio.com/request-pricing/
И где «всё время»?
2) Так то они способны и даже пароли знают (если не забыли), но в реальности root никто пользовать не собирается с вероятностью 99,99%
3) Если переложить файлы в личную папку — права унаследуются от этой папки, у всех будет доступ для чтения, в описанном случае только мама (или root) могут их удалить. Ну это при копировании в винде естественно. Мне кажется наоборот всё становится логичным, все права будут такими, как задано при конфигурации.
Снапшоты на ответственные датасеты настроены и сейчас столкнулся с тем, что при назначении прав и владельцев — к ним это не применяется, что не критично, но нужно будет проапдейтить, указав это.
Кто его знает, что там ещё за бонусы есть.
Так вот. Поднимаем AD на синолоджи, вводим компьютеры в домен и вуаля, рулим доменными пользователями и доступами.
Очень и очень серьезно, надежно в работе и в целом проще, как мне кажется.
Иначе самба становиться завирусованной помойкой.
это послужило сильным поводом того что я мигрировал на линукс, в процессе миграции необходимость запускать с шары исчезла как таковая
Скорее всего это актуально для какой-либо организации, где много пользователей и у многих из них есть разрешения записи, если, конечно, там кто то решит использовать Xigmanas, а не что-то «коробочное».