Приветствую, авантюрист. При работе на любой операционной системе айтишник должен уметь работать с некими базовыми задачами. К таким задачам можно смело отнести работу с сетевыми файловыми ресурсами. Подключение сетевых «шар» (от англ. share) или сетевых дисков в любом предприятии или организации — это база, которую нужно понимать, уметь настраивать и обслуживать любому мало-мальски айти специалисту. Тема это, мягко говоря, обширная и непростая. Про одну только настройку сервера сетевых дисков Samba можно писать бесконечно. Но с чего-то надо начинать. Условимся, что у нас есть настроенный и рабочий файловый сервер. На самом деле абсолютно не важно, на какой ОС он настроен. Нам нужно знать только адрес, имя «открытого» каталога и учетные данные.
Команда mount
Вообще, команда mount — это утилита для монтирования файловых систем, не обязательно сетевых. К примеру, через mount мы монтируем подключаемые к компьютеру флешки. Совсем недавно всё это делалось ручками. Сейчас эти процессы автоматизированы и требуют только нажатия соответствующей кнопки интерфейса. Общий синтаксис утилиты в случае монтирования такой.
mount [options] <source> <directory>
Команду нужно выполнят от рута
Давайте рассмотрим пример с флешкой или внешним жестким диском, что в принципе не важно. Итак, подключаем устройство в USB порт, далее командой lsblk (вообще советую запомнить эту команду, она довольно полезная) смотрим, как оно у нас определилось.
Видим, что наш внешний диск определился как /dev/sda и на нем есть 1 раздел, следовательно, /dev/sda1.
Теперь, чтобы примонтировать файловую систему, которая находится на разделе /dev/sda1, мы воспользуемся командой.
mount /dev/sda1 /mnt/my_disk
После выполнения данной команды мы увидим содержимое съемного диска в каталоге /mnt/my_disk. Каталог я предварительно создал. Утилита сама определит, какой тип файловой системы используется, но если это необходимо, тип файловой системы можно указать через ключ -t.
mount -t ntfs /dev/sda1 /mnt/my_disk
В некоторых дистрибутивах у тебя не будет поддержки файловой системы NTFS. Для ее корректной работы нужно установить соответствующее ПО. В ALT Linux, например, всё работает из коробки.
Монтирование сетевых дисков
Принцип остается точно такой же, мы указываем что и куда монтировать, но в качестве типа файловой системы пишем cifs. Ну и конечно же нужно указать данные авторизации на сервере. Возьмем пример. Есть сервер с адресом fs.somedomen.ru, на этом сервере есть каталог share. У пользователя alex с паролем 1234 есть полный доступ к этому каталогу. Следовательно что бы подключить данный каталог к локальной файловой системе пишем следующую команду:
mount -t cifs //fs.somedomen.ru/share -o username=alex,password=1234 /mnt/alex_share
После чего, если данные авторизации верные содержимое каталога share на сервере fs.somedomen.ru будет смонтировано в каталог /mnt/alex_share
Если мы хотим использовать данные для авторизации из домен-контроллера, то вместо логина/пароля мы указываем опцию sec=krb5. Команда будет выглядеть следующим образом:
mount -t cifs //fs.somedomen.ru/share -o sec=krb5 /mnt/alex_share
В этом случае логин и пароль будут браться из тикетов (ну или передаваться сам тикет, тут я не особо компетентен), полученных от домен-контроллера по протоколу Kerberos. Само собой, компьютер должен состоять в домене и корректно настроен.
Права доступа
Команда, приведенная выше, смонтирует каталог, расположенный на удаленном сервере, но что с правами? Чей это будет каталог? Какие будут права? Какие будут права на созданные после монтирования файлы, каталоги? Давайте разбираться.
Чей будет каталог? Ответ — каталог будет принадлежать локальному пользователю root. Права будут 755. Это означает, что читать могут все, а вот что-то записать сможет только root. Попытка применить команду chmod или chown ни к чему не приведет. Такая ситуация не очень удобна. Как же сделать примонтированный каталог нашим ( Что бы он принадлежал моему ЛОКАЛЬНОМУ пользователю. ) ? Во время монтирования мы должны указать в опциях параметры uid и gid. Например, я работаю в системе под ЛОКАЛЬНЫМ пользователем zerg, и я бы хотел, чтобы примонтированный каталог принадлежал именно этому пользователю.
Получаем id пользователя zerg командой id -u zerg. Аналогично получаем id группы командой id -g zerg.
Как видно, id юзера равен 1000, так же как и id группы. Теперь вставляем эти значения в команду.
mount -t cifs //fs.somedomen.ru/share -o username=alex,password=1234,uid=1000,gid=1000 /mnt/alex_share
Теперь примонтированный каталог будет принадлежать пользователю zerg. А значит, данный пользователь будет иметь полный доступ.
Надо иметь в виду, что сервер также может накладывать на сетевые каталоги ограничения. На сервере мы авторизуемся как alex и условились, что у данного пользователя полный доступ на стороне сервера.
А вот кому же принадлежат созданные уже после монтирования файлы и каталоги? На нашей локальной файловой системе всё принадлежит ЛОКАЛЬНОМУ пользователю, id которого был указан в команде mount. А вот на сервере всё происходит от имени пользователя alex. Вновь созданные файлы и каталоги на сервере будут созданы от имени alex. Это нужно иметь в виду.
Теперь остается вопрос прав. Пока у нас права 755, и вновь созданные файлы также будут иметь права 755. Для того чтобы поменять это, есть опции dir_mode и file_mode соответственно.
mount -t cifs //fs.somedomen.ru/share -o username=alex,password=1234,uid=1000,gid=1000,dir_mode=0777,file_mode=0777 /mnt/alex_share
Вместо 777 можно указывать любые необходимые права.
Тут опять же стоит сделать ремарку, что на стороне сервера это тоже всё может быть ограниченно, но мы, напомню, условились, что на стороне сервера у нас полный доступ.
Итог
Работа с файловыми «шарами» на линукс-системах с первого взгляда выглядит довольно запутанно. Но попрактиковавшись в их настройке пару раз, всё встает на свои места и в дальнейшем уже не вызывает таких больших трудностей. Вспомни, как ты первый раз настраивал сеть на Windows. Это было то еще приключение. Стоит сказать пару слов про автоматизацию процесса монтирования при включении компьютера. Тут вариантов в зависимости от задачи несколько, и это всё довольно обширно. Я не стал перегружать этим статью, а лучше когда-то сделаю отдельную. На этом всё. Удачи, авантюрист.