В процессе создания и конфигурирования своего тестового веб-сервера на базе Raspberry Pi Zero W, у меня возникла задача монтирования сетевого ресурса (сетевого диска), размещенном на другом устройстве моей домашней сети - своеобразном NAS. Типичный подход для ОС Linux - организация к нему доступа через описание точки монтирования в файле fstab оказался несколько несостоятельным. Сетевая "шара", бесспорно, монтировалась и можно было спокойно с ней работать, но до первого "сетевого инцидента". Стоило только Raspberry Pi переподключиться к точке доступа Wi-Fi, как сетевой диск сразу становился недоступен. Приходилось заново "передергивать" fstab, чтобы система восстановила к нему доступ.
Такое положение дел, естественно, мало кого устроит. Но решение нашлось, и это решение - один из юнитов systemd.
Пожалуй, стоит оговориться, что свои "эксперименты" я проводил в родной для моей "малинки" Raspberry Pi OS, которая использует systemd как подсистему инициализации по умолчанию. Если у Вас иной дистрибутив Linux, убедитесь, что он так же работает на systemd. В противном случае, описанное ниже решение у Вас работать не будет.
Я не буду описывать как работает systemd, а также затрагивать специфику его организационной структуры управления процессами - это тема очень сложна и обширна и ее никак не описать в такой заметке как эта. Лишь отмечу, что по задумке создателей systemd, его структурными "кирпичиками" являются специальным образом оформленные файлы конфигураций, которые принято называть юнитами (от английского unit) или модулями. И из всего имеющегося многообразия юнитов systemd, сегодня нас особенно будут интересовать два: mount и automount.
Но мы не будем создавать их вручную для нашего конкретного случая, как это предлагается в большинстве похожих "решений", которые Вы можете найти в интернет. Для нас их создаст сам systemd, или точнее один из его "генераторов".
Логика проста - systemd обладает множеством своих собственных генераторов файлов конфигураций, которые динамически преобразуют стандартные системные файлы настроек в юниты systemd, которые уже он использует дальше в своей работе. Так, одним из таких генераторов обрабатывается при загрузке системы и файл fstab. И все что нам требуется - это дополнить монтируемый через него сетевой диск специальной опцией монтирования - x-systemd.automount. Собственно, это то, что и ожидается в первую очередь от пользователя. Давайте посмотрим, как это выглядит на практике.
В нашу задачу входит настройка автоматического монтирования сетевого ресурса (сетевого диска) располагающегося в той же сети, что и компьютер под управлением ОС Linux. Сетевой ресурс создан на основе пакета Samba (у Вас это может быть и сетевая "шара", созданная на базе ОС Windows) и взаимодействие с ним проходит по протоколу SMB.
Шаг 1. Для того, чтобы в ОС Linux можно было работать с сетевыми ресурсами по протоколу SMB/CIFS, необходимо установить пакет cifs-utils. В некоторых дистрибутивах ОС Linux он идет в штатной установке (например, в Raspberry Pi OS этот пакет уже был включен с самого начала), в других же его необходимо устанавливать самостоятельно. Для установки в Debian-подобных дистрибутивах:
sudo apt-get install cifs-utils
Для установки в RedHat-подобных дистрибутивах:
sudo yum install cifs-utils
Шаг 2. Создание точки монтирования сетевого диска. В теории, ничем не запрещено создавать точку монтирования там, где Вам удобно, но в соответствии с рекомендуемым стандартом иерархии файловой системы, лучше всего все сменные носители (косвенно отнесем к ним и наш сетевой диск :)))) монтировать в директорию /media. Для этого создадим в директории /media поддиректорию с любым наименованием, например, share.
sudo mkdir /media/share
Шаг 3. Создание файла авторизации для сетевого ресурса. Шаг опциональный и требуется лишь тем, у кого доступ к сетевому диску организован по логину и паролю. Если у Вас сетевая "шара" позволяет анонимный вход, переходите к следующему шагу. Тем же, у кого доступ к сетевому диску только по паролю, необходимо создать файл авторизации со следующей структурой (содержимым):
username=Логин_к_сетевому_диску
password=Пароль_к_сетевому_диску
Учитывая, что мы планируем подключать наш сетевой диск от пользователя root, то я рекомендую файл авторизации создавать в домашнем каталоге root (/root). Таким образом мы повысим степень защиты данных авторизации от несанкционированного доступа. Для создания файла Вы можете воспользоваться абсолютно любым текстовым редактором, в котором привыкли работать, например, nano:
sudo nano /root/.nascredentials
Имя файла авторизации Вы вправе использовать абсолютно любое. Главное, чтобы потом сами могли быстро понять, что это за файл и для чего он находится в директории /root :))). В моем случае это .nascredentials (именно с символом точки в начале).
Вводим данные для авторизации и сохраняем файл (не забываем указывать свои данные для авторизации):
После этого нам необходимо изменить права на только что созданный файл (.nascredentials), чтобы доступ к нему имел только пользователь root. Для этого нам потребуется утилита chmod:
sudo chmod 700 /root/.nascredentials
Шаг 4. Внесение записи о точке монтирования в файл /etc/fstab. Если Вы не знаете, что из себя представляет файл fstab, для чего он служит и какую структуру имеют записи, вносимые в него, то я отправляю Вас вот к этой замечательной статье, где данные вопросы очень хорошо раскрыты. В общем виде нам необходимо указать что монтировать, куда монтировать, с какой файловой системой и с какими параметрами.
Что монтировать - это сетевой адрес устройства, на котором находится подключаемый сетевой диск. В качестве адреса настоятельно рекомендую использовать его IP-адрес. Например, в моем случае это //192.168.1.1/usb_disk. Хочу обратить внимание, что у протокола SMB есть свой нюанс, который не позволяет просто подключить удаленной компьютер, на котором есть сетевая "шара" (возможно даже и не одна), например, указав просто //192.168.1.1. Необходимо указать, в то числе, и наименование подключаемого сетевого ресурса на удаленном узле (в моем случае это usb_disk).
Куда монтировать - это директория, которую мы создали на Шаге 2 (см. выше).
С какой файловой системой - для подключения сетевых директорий используется файловая система cifs. Ее поддержку мы установили на Шаге 1.
С какими параметрами - сначала приведу всю строчку параметров, которая используется у меня при подключении сетевого диска, а потом поясню для чего служит каждый из них. Итак, мои параметры подключения сетевого ресурса:
x-systemd.automount,credentials=/root/.nascredentials,
iocharset=utf8,file_mode=0777,dir_mode=0777,gid=1000,uid=1000
Что же значит вся эта "абракадабра":
x-systemd.automount - параметр, который указывает генератору systemd сформировать юнит .automount для подключаемого сетевого диска. Собственно, ради него все и затеяно.
credentials=/root/.nascredentials - в параметре credentials мы передаем путь до файла авторизации (не забываем указывать свой путь, если вы разместили файл авторизации в другом месте или под другим именем), который мы создали на Шаге 3. Если доступ к вашему сетевому ресурсу анонимный, то параметр credentials Вам необходимо опустить.
iocharset=utf8 - параметр задает кодировку подключаемой файловой системы. Как правило, все современные файловые системы работают в кодировке UTF-8.
file_mode=0777 - параметр, устанавливающий максимальные права для всех на доступ к файлам подключаемого сетевого диска.
dir_mode=0777 - параметр, устанавливающий максимальные права для всех на доступ к директориям подключаемого диска.
gid=1000 - параметр, определяющий группу владельца подключаемого сетевого диска (иными словами - какая группа будет считаться владельцем сетевого диска).
uid=1000 - параметр, определяющий идентификатор владельца подключаемого сетевого диска (иными словами - какой пользователь будет считаться владельцем сетевого диска).
Как узнать gid и uid и почему именно стоят в параметрах? Для того, чтобы узнать эти идентификаторы, достаточно в командной строке набрать команду id:
Т.е. я указываю основным владельцем подключаемого ресурса пользователя, которым работаю в системе (в моем случае - пользователь oxide). Если не указать эти параметры при монтировании, то основным пользователем будет считаться пользователь, от имени которого запущен процесс монтирования (в подавляющем большинстве случаев - это root). Но и тут есть своя "оговорка" (это для любознательных) - все это "работает" если только удаленный компьютер сам не сообщает идентификатор пользователя. Если же сообщает, то права на файлы и директории будут ровно теми, которые записаны в файловой системе удаленного узла. И тут уже придется использовать несколько иные параметры подключения.
Итак, итоговая строчка монтирования нашего сетевого диска выглядит так (опции дампа и проверки файловой системы равны 0):
//192.168.1.1/usb_disk /media/share cifs
x-systemd.automount,credentials=/root/.nascredentials,
iocharset=utf8,file_mode=0777,dir_mode=0777,gid=1000,uid=1000 0 0
Или как это выглядит в терминале:
В качестве совета: прежде чем вносить изменения непосредственно в файл /etc/fstab, протестируйте получившуюся итоговую строчку монтирования вручную, используя команду mount.
Шаг 5. Перезагрузка и тестирование. После внесения изменений в файл /etc/fstab перезагрузите компьютер, чтобы генератор systemd сформировал при загрузке соответствующие файлы mount и automount. Если Вы все сделали правильно, то в директории /run/systemd/generator/ у Вас должны были появиться два новых файла, у меня это: media-share.mount и media-share.automount (названия файлов могут отличаться в зависимости от наименования точки монтирования, которую Вы используете для подключения сетевого диска).
Поскольку сформированные файлы - модули systemd, их, как и любые модули, можно проверять на статус работы. Для этого необходимо использовать утилиту systemctl:
systemctl status наименование_модуля
Проверим работу модулей на моей машине:
Как Вы можете видеть на скриншотах, модули замечательно работают. При этом сетевой диск смонтирован на старте системы модулем .mount и до сих пор примонтирован. В свою очередь модуль .automount проверяет наличие доступа к сетевому диску при каждом обращении к нему и в случае отсутствия доступа пытается его восстановить. Отдельно стоит отметить, что удобство использования модулей systemd состоит еще и в автоматической проверке наличия доступа к сети. Т.е. модули .mount и .automount не завершатся неудачей просто потому что не успело появиться сетевое подключение. Свои попытки примонтировать сетевой диск они будут осуществлять только при наличии сетевого соединения.
А на этом у меня сегодня всё! Пишите в комментариях всё ли у Вас получилось :))).
Комментариев нет:
Отправить комментарий