Монтировать папку windows в linux — Ваш верный помощник с OS Windows

В этой статье мы рассмотрим, как в Linux смонтировать общую сетевую папку, расположенную на хосте Windows. В Windows для доступа к общим сетевым папкам используется протокол SMB (Server Message Block), который ранее назывался CIFS (Сommon Internet File System). В Linux для доступа к сетевым папкам Windows по протоколу SMB можно использовать клиент cifs-utils или Samba.

Содержание:

Смонтировать сетевую папку в Linux с помощью cifs-util
Автоматическое монтирование сетевой папки в Linux
Linux: подключиться к сетевой папке с помощью клиента samba

Совет. Для доступа к сетевым папкам по SMB/CIFS используется порт TCP/445. Для разрешения имени используются порты UDP 137, 138 и TCP 139. Если эти порты закрыты, вы сможете подключиться к сетевой папке Windows только по IP адресу.

Смонтировать сетевую папку в Linux с помощью cifs-util

Вы можете смонтировать сетевую папку, находящуюся на Windows хосте, с помощью утилит из пакета cifs-util. Для установки пакета выполните команду:

В Ubuntu/Debian: $ sudo apt-get install cifs-utils
В CentOS/Oracle/RHEL: $ sudo dnf install cifs-utils

Создайте точку монтирования:

$ sudo mkdir /mnt/share

Теперь вы можете смонтировать сетевую папку с компьютера Windows под пользователем User03с помощью команды:

$ sudo mount.cifs //192.168.31.33/backup /mnt/share -o user=User03

Укажите пароль пользователя Windows для подключения к сетевой папке.

При подключении сетевой SMB папки можно задать дополнительные параметры:

$ sudo mount -t cifs -o username=User03,password=PasswOrd1,uid=1000,iocharset=utf8 //192.168.31.33/backup /mnt/share

//192.168.31.33/backup – сетевая папка Windows
/mnt/share – точка монтирования
-t cifs – указать файловую систему для монтирования
-o опции монтирования (эту опцию можно использовать только с правами root, поэтому в команде используется sudo)
username=User03,password=PasswOrd1 – имя и пароль пользователя Windows, у которого есть права доступа к сетевой папке. Можно указать имя пользователя guest, если разрешен анонимный доступ к сетевой папке
iocharset=utf8 – включить поддержку кодировки UTF8 для отображения имен файлов
uid=1000 – использовать этого пользователя Linux в качестве владельца файлов в папке

По умолчанию шары Windows монтируются в Linux с полными правами (0755). Если вы хотите изменить права по-умолчанию при монтировании, добавьте в команду опции:

dir_mode=0755,file_mode=0755

Если вы хотите использовать имя компьютера при подключении сетевого каталога Windows, добавьте в файл /etc/hosts строку:

IP_АДРЕС    ИМЯ_КОМПЬЮТЕРА

Чтобы не указывать учетные данные пользователя Windows в команде монтирования сетевой папки, их можно сохранить в файле.

Например:

$ mcedit ~/.windowscredentials

Добавьте в файл:

username=User03
password=PasswOrd1

Для подключения к папке под анонимным пользователем:

username=guest
password=

Если нужно указать учетную запись пользователя из определенного домена Active Directory, добавьте в файл третью строку:

domain = vmblog.ru

Измените права на файл:

$ chmod 600 ~/.windowscredentials

Теперь при подключении сетевой папки вместо явного указания имени пользователя и пароля можно указать путь к файлу:

$ sudo mount -t cifs -o credentials=/home/sysops/.windowscredentials,uid=1000,iocharset=utf8 //192.168.31.33/backup /mnt/share

Отмонтировать сетевую SMB папку:

$ sudo umount /mnt/share

Автоматическое монтирование сетевой папки в Linux

Можно настроить автоматическое монтирование сетевой папки Windows через /etc/fstab.

$ sudo mcedit /etc/fstab

Добавьте в файл следующую строку подключения SMB каталога:

//192.168.31.33/backup /mnt/share cifs user,rw,credentials=/home/sysops/.windowscredentials,iocharset=utf8,nofail,_netdev 0 0

rw – смонтировать SBM папку на чтение и запись
nofail – продолжить загрузку ОС если не удается смонтировать файловую систему
_netdev – указывает что подключается файловая система по сети. Linux не будет монтировать такие файловые системы пока на хосте не будет инициализирована сеть.

Вы можете указать версию протокола SMB, которую нужно использовать для подключения (версия SMB 1.0 считается небезопасной и отключена по-умолчанию в современных версиях Windows). Добавьте в конец строки с настройками подключения параметр vers=3.0.

//192.168.31.33/backup /mnt/share cifs user,rw,credentials=/home/sysops/.windowscredentials,iocharset=utf8,nofail,_netdev,vers=3.0 0 0

Если на стороне хоста Windows используется несовместимая (старая версия) SMB, при подключении появится ошибка:

mount error(112): Host is downилиmount error(95): Operation not supported

Чтобы сразу смонтировать сетевую папку, выполните:

$ mount -a

Linux: подключиться к сетевой папке с помощью клиента samba

Установите в Linux клиент samba:

В Ubuntu/Debian: $ sudo apt-get install smbclient
В CentOS/Oracle/RHEL: # dnf install smbclient

Для вывода всех SMB ресурсов в локальной сети:

$ smbtree -N

Вывести список доступных SMB папок на удаленном хосте Windows:

smbclient -L //192.168.31.33 -N

Если в Windows запрещен анонимный доступ, появится ошибка:

session setup failed: NT_STATUS_ACCESS_DENIED

В этом случае нужно указать учетную запись пользователя Windows, которую нужно использовать для подключения:

smbclient -L //192.168.31.33 -U User03

Если нужно использовать учетную запись пользователя домена, добавьте опцию –W:

smbclient -L //192.168.31.33 -U User03 –W Domain

smbclient вывести список общих папок на компьютере windows

Для интерактивного подключения к сетевой папке Windows используется команда:

smbclient //192.168.31.33/backup -U User03 -W Domain

или

smbclient //192.168.31.33/backup -U User03

Для анонимного доступа:

smbclient //192.168.31.33/backup -U Everyone

После успешного входа появится приглашение:

smb: \>

Вывести список файлов в сетевой папке:

dir

Скачать файл из сетевой папки Windows:

get remotefile.txt /home/sysops/localfile.txt

Сохранить локальный файл из Linux в SMB каталог:

put /home/sysops/localfile.txt remotefile.txt

Можно последовательно выполнить несколько команд smbclient:

$ smbclient //192.168.31.33/backup -U User03 -c "cd MyFolder; get arcive.zip /mnt/backup/archive.zip"

Полный список команд в smbclient можно вывести с помощью команды help. Команды smbclient схожи с командами ftp клиента.

При использовании команды smbclient может появиться ошибка:

Unable to initialize messaging contextsmbclient: Can't load /etc/samba/smb.conf - run testparm to debug it.

Чтобы исправить ошибку, создайте файл /etc/samba/smb.conf.

Если на хосте Windows отключен протокол SMB 1.0, то при подключении с помощью smbclient появится ошибка:

Reconnecting with SMB1 for workgroup listing.
protocol negotiation failed: NT_STATUS_CONNECTION_RESET
Unable to connect with SMB1 -- no workgroup available.

Источник

Обновлено: 21.03.2025
Опубликовано: 18.07.2016

Используемые термины: CIFS, Linux.

Протокол CIFS (SMB) позволяет работать с общими папками. В инструкции будет рассказано, как в системах на базе Linux можно настроить клиент для подключения к файловому серверу, который работает по данному протоколу.

Подготовительная работа
Синтаксис mount
Ручное монтирование
Автоматическое монтирование
Примеры
Дополнительная информация

Подготовка

Установка пакетов

Для монтирования общей папки необходимо установить набор утилит для работы с CIFS (в противном случае, мы получим ошибку mount.cifs команда не найдена).

а) Для систем RPM (РЕД ОС, Rocky Linux, CentOS):

yum install cifs-utils

б) Для DEB-систем (Astra Linux, Debian, Ubuntu):

apt update

apt install cifs-utils

Сетевые порты

Если мы будем монтировать сетевую папку, сервер которой находится за брандмауэром, необходимо открыть следующие порты:

137/UDP
138/UDP
139/TCP
445/TCP

Данные команды нет необходимости выполнять на клиентах. Только на стороне сервера.

В зависимости от используемого типа фаервола, команды будут отличаться.

а) iptables (как правило, на системах DEB):

iptables -I INPUT -p tcp —dport 445 -j ACCEPT

iptables -I INPUT -p udp —dport 137:138 -j ACCEPT

iptables -I INPUT -p tcp —dport 139 -j ACCEPT

Применяем настройки:

apt install iptables-persistent

netfilter-persistent save

б) firewalld (как правило, на системах RPM):

firewall-cmd —permanent —add-service=samba

firewall-cmd —reload

Синтаксис

mount.cifs <папка на сервере> <во что монтируем> <-o опции>

* вместо mount.cifs можно написать mount -t cifs.

Пример:

mount.cifs //192.168.1.1/public /mnt

* простой пример монтирования папки public на сервере 192.168.1.1 в локальный каталог /mnt.

Если нам не известны расшаренные папки на сервере, мы можем воспользоваться утилитой smbclient. Для начала установим ее.

а) на RPM (Rocky Linux / РЕД ОС / Red Hat / CentOS / Fedora):

yum install samba-client

б) на Deb (Debian / Ubuntu / Astra Linux / Mint):

apt install samba-client

Теперь вводим:

smbclient -L 192.168.1.1

или, при необходимости авторизоваться на файловом сервере:

smbclient -L 192.168.1.1 -U username

Ручное монтирование

Теперь монтирование можно выполнить следующей командой:

mount.cifs //192.168.1.10/share /mnt -o user=dmosk

* в данном примере будет примонтирован каталог share на сервере 192.168.1.10 в локальную папку /mnt под учетной записью dmosk.

То же самое, с использованием домена:

mount.cifs //192.168.1.10/share /mnt -o user=dmosk,domain=dmosk.local

Автоматическое монтирование CIFS через fstab

Для начала создаем файл, в котором будем хранить данные авторизации при подключении к общей папке:

vi /root/.smbclient

И добавляем в него данные следующего вида:

username=dmosk
password=dPassw0rd
domain=dmosk.local

* в этом примере создана пара логин/пароль — dmosk/dPassw0rd; domain указывать не обязательно, если аутентификация выполняется без него.

Задаем права на созданный файл, чтобы доступ был только у пользователя, скажем, root:

chmod 600 /root/.smbclient

chown root:root /root/.smbclient

Теперь открываем конфигурационный файл fstab:

vi /etc/fstab

и добавляем в него следующее:

//192.168.1.10/share /mnt cifs user,rw,credentials=/root/.smbclient 0 0

* в данном примере выполняется монтирование общей папки share на сервере с IP-адресом 192.168.1.10 в каталог /mnt. Параметры для подключения — user: позволяет выполнить монтирование любому пользователю, rw: с правом на чтение и запись, credentials: файл, который мы создали на предыдущем шаге.

Чтобы проверить правильность настроек, вводим следующую команду:

mount -a

Примеры использования опций

Версии SMB

Если на стороне Windows используется старая или слишком новая версия протокола SMB, при попытке монтирования мы можем получить ошибку mount error(112): Host is down. Чтобы это исправить, указываем версию:

mount.cifs //192.168.1.10/share /mnt/ -o vers=1.0

* монтирование по протоколу SMB1.0

Монтирование от гостевой учетной записи

Если сервер принимает запросы без логина и пароля, то клиент подключается, как гость:

mount.cifs //192.168.1.10/share /mnt -o guest

или в fstab:

//192.168.1.10/share /mnt cifs guest 0 0

Для монтирования шары Windows, иногда, недостаточно указать опцию guest. Нужно делать так:

mount.cifs //192.168.1.10/share /mnt -o user=guest,pass=»

Или в fstab:

//192.168.1.10/share /mnt cifs guest,pass 0 0

Права на примонтированные каталоги

При монтировании папки мы можем указать определенные права:

mount.cifs //192.168.1.10/share /mnt -o file_mode=0777,dir_mode=0777

Для указания владельца, который будет назначен для примонтированного каталога, используем:

mount.cifs //192.168.1.10/share /mnt -o uid=33,gid=33

* чтобы посмотреть идентификаторы пользователя, вводим id -u <имя пользователя> и id -g <имя группы>.

Why It May Not Work?

In older versions of Linux distros and Windows 7 everything worked fine because they used the SMB1 protocol. However, there have been several changes recently. In 2017, the Wannacry virus emerged, which exploited vulnerabilities in the SMB1 protocol. As a result, modern versions of Windows have disabled support for SMB1 and now use SMB3 by default. Samba has also disabled SMB1 since version 4.11. However, SMB2 and SMB3 lack support for device discovery in the local network.

In general, this is no longer necessary because there is a network discovery protocol called Zeroconf. In Linux, its open-source implementation, Avahi, is used. Linux servers and NAS storage can publish themselves on the local network using this protocol. So that, there is no need to support it in SMB. However, Microsoft decided to use its own protocol called WS-Discovery, and that’s where the problems began.

At the time of writing this article, Linux system has issues with discovering shared folders in the local network. The Nautilus file manager in GNOME does not support WS-Discovery at all, and there are no production-ready terminal utilities for it either. You can track the current status of implementing WS-Discovery support in this GVFS issue. However, in 2020, the KDE team added support for this protocol in the Dolphin file manager using kdsoap-ws-discovery-client.

Later, a program for KDE called Smb4k appeared, which can discover network resources using Avahi and the WS-Discovery protocol, but it needs to be compiled with a special option. So that, in GNOME, you can only open a Windows shared folder by knowing the IP address of the computer where it is located. Whereas in KDE, it is a bit more convenient to do so.

Ensure that Everything is Set Up Correctly in Windows

Previously, it was enough to go to File Explorer and enable file sharing there. But it no longer works that way. First, you need to make your current network private in Windows. By default, only private networks are considered secure, and Windows machines can be discovered in them. To do this, open Settings -> Network & Internet -> Ethernet and select Network Profile Type -> Private Network:

If your current network is wireless, you should do the pretty same thing. Next, go back and select Advanced Sharing Settings. In this window, enable Network discovery and File and printer sharing:

Finally, you need to ensure that the firewall is configured correctly and allows SMB connections. To do this, go back to the main Settings menu, then open Privacy & Security -> Firewall & network protection. Click on Allow an app through the firewall:

Make sure that File and printer sharing and Network discovery are enabled for Private networks:

That’s it. Now you can go to your Linux machine.

Although there are no command-line tools for working with WS-Discovery, you can try to find devices with shared resources using Nmap. This program cannot search for resources like Avahi does, but it can help you find IP addresses with an open port 445. This port is used by SMB. To do this, you need to install the following packages (Ubuntu):

sudo apt install nmap smbclient

Or Fedora:

sudo dnf install nmap samba-client

Also, you need to find out the IP address range of your local network. You can take your IP address and mask and just replace the fourth digit with zero. For example:

ip -br a

The command for the search will look like this. Replace 192.168.124.0/24 with your local network address range and run it in the the terminal window with sudo privileges:

nmap -p 445 --open -n -Pn 192.168.124.0/24

The -p option specifies the port 445, -Pn option disables ICMP discovery and treats all IP addresses as alive, -n disables DNS hostname resolution. The command may take quite a while, but as a result, it will find hosts with open port 445 if such hosts exist in your local network:

This can’t be considered as normal network discovery, but it works. Now you can use smbclient to see which shared folders are on the server that you found. For example:

smbclient -L 192.168.124.63

The command will ask you to enter the share password. Usually, it is password for your Windows user, and then it will show all available shared folders:

Now let’s have a look at how to mount them.

To open a shared folder in KDE, you can use the Dolphin file manager. As I mentioned earlier, here you can see all available computers that have network drive on the local network. To do this, run Dolphin, then open Network, and then Shared Folders (SMB):

Click on one of the resources and enter the username and password to view the available folders:

This is what shared folders from Windows 11 look like. Here you can find windows files:

If network discovery does not work in your case, you can still enter the IP address of the resource in the text field at the top of the window and connect to it. For example, smb://192.168.124.63/

If you want to connect to a Windows shared folder in the GNOME graphical interface, you can use the Nautilus file manager. Open Other Locations and find at the bottom of the window the inscription Connect to Server and a field for entering an address.

There’s no point in opening the Windows Network item, because GVFS, which is used in GNOME for disk mounting, does not support the WS-Discovery protocol. To connect to a remote windows share located on a server with IP 192.168.124.63, enter this address and press the Connect button:

smb://192.168.124.63

In the next window, you need to enter a password and after that, you can view the files of the shared folder:

After this, you can browse your windows folders.

Additionally, you can use a shortcut on the left panel to access a remote share which is already mounted.

If you want to mount windows share in the terminal, you can use cifs-utils and the mount command. Firstly, install the cifs-utils package. The command for Ubuntu:

sudo apt install cifs-utils

In Fedora:

sudo dnf install cifs-utils

Now, you can execute the mount command specifying the cifs file system type and the username option. Note that you can’t mount the root of the cifs share, you need to add any folder in the path. For example, Users on 192.168.124.63:

sudo mount -t cifs -o username=losst //192.168.124.63/Users /mnt/

If you want to have write access to the windows share folder, you need to add the uid option with the identifier of your user. For the first user, it’s usually 1000:

sudo mount -t cifs -o username=losst,uid=1000 //192.168.124.63/Users /mnt/

You can find the identifier of the current user in the UID environment variable:

echo $UID

If you want to mount share automatically at system startup, you need to save the share username and password in a credentials file, for example, /etc/share/windows-credentials. For instance:

sudo mkdir -p /etc/share/

username=losst password=password domain=workgroup

And then add the following line to the /etc/fstab file:

//192.168.124.63/Users /mnt/share cifs credentials=/etc/share/windows-credentials,uid=1000,nofail 0 0

The nofail option is needed to allow your computer to boot even if the remote folder could not be mounted. After this, reload systemd settings:

sudo systemctl daemon-reload

Create the mount point directory:

sudo mkdir -p /mnt/share

You can check that everything is working using the following command:

sudo mount /mnt/share

If everything is ok, you could see contents of mounted share in the /mnt/share folder:

Wrapping Up

In this article, we looked at how to mount Windows network share in Linux using a graphical interface or in the terminal. Despite some difficulties, this can be used quite effectively. Do you know any other applications or scripts which can help with that? Share their names in the comments section below.

The article is distributed under Creative Commons ShareAlike 4.0 license. Link to the source is required.

Источник

Монтируем шары для юзеров

Уровень сложностиСредний

Время на прочтение9 мин

Количество просмотров28K

Всем привет. Монтируете ли вы шары, как их монтирую я? Вероятно, нет, т. к. очень крутой опции multiuser на просторах интернета уделено слишком мало внимания, а man mount.cifs в её отношении весьма немногословен и скуп на наглядные примеры. Именно это и сподвигло меня поделиться с вами парой «рецептов», которые могут облегчить вам и вашим пользователям движение в сторону отечественных десктопов и ИТ-инфраструктур.

Как обычно у меня на стенде российская RedOS 7, просто как образец операционной системы с не самым древним набором пакетов и инициализацией посредством systemd. С другими дистрибутивами вы справитесь самостоятельно. Юзеры и компьютеры живут в виндовом домене, а из отягчающих обстоятельств — наличие многопользовательских рабочих мест (сменный персонал).

Отечественные операционные системы (а это в основном Linux) дают нам возможность монтировать сетевые файловые системы несколькими методами, которые создавались с целью обойти какие-либо ограничения безопасности, либо для снижения сложности ручной процедуры монтирования конечным пользователем. Это и классическое монтирование через fstab или просто ручной вызов mount, варианты automount/autofs, а также монтирование в пространстве пользователя посредством gvfs. Способов много, и все они имеют несомненные достоинства, основное из которых — они работают.

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

На мой взгляд, решением всех этих проблем является монтирование сетевых ресурсов с опцией multiuser. Данная опция позволяет иметь одновременный доступ к сетевому ресурсу по одному подключению нескольким пользователям под своими учётными данными и со своими правами. Пользователь root, либо система при загрузке, как обычно монтируют удалённую файловую систему в каталог, и каждый пользователь видит в нём только те файлы/каталоги, на которые у него назначены права на файловом сервере. Почти как NFS, только с учётом особенностей «однопользовательского» протокола CIFS.

В чём основные плюсы данного решения:

Настраивается глобально, конфигурация рабочих мест унифицирована.
Чёткое разграничение прав. Каждый пользователь видит только то, что ему разрешено, а root монтирует файловые ресурсы под весьма ограниченным в правах «техническим» пользователем.
У всех пользователей одинаковые пути — можно обмениваться абсолютными ссылками и пропадают проблемы с программами, не умеющими работать с gvfs.
Высокая производительность.
Отсутствует необходимость выдачи избыточных прав пользователям.

Далее прорабатываем два варианта в зависимости от методов аутентификации.

▍ Рецепт 1. Монтирование с логином/паролем

Стандартная ситуация, когда для доступа к ресурсу необходимо ввести логин и пароль. Варианты такие не редкость, например, у меня эксплуатируется старенький NAS, который решили не интегрировать в домен, а пользоваться его внутренней базой пользователей.

На клиентской машине добавляем строчку монтирования в fstab:

//NAS/FOTO	/mnt/foto	cifs	cred=/root/.config/cifscred,multiuser,file_mode=0600,dir_mode=0700	0 0

Как видим, опций немного. Обязательно указываем multiuser, а опцией cred задаём файл, содержащий данные для аутентификации на сервере. Можно вместо опции cred использовать совокупность опций username/password/domain (man mount.cifs), но это несколько несекьюрно с моей точки зрения Соответственно, у рута создаём файлик ~/.config/cifscred вот такого вида:

username=needly
password=P@ssw0rd
domain=CORP

Перезагружаемся и видим следующую картину:

Ресурс смонтировался.
Пользователь root кое-что видит. На самом деле иногда удобно не держать его бесправным, а дать доступ к каким-нибудь полезным папкам.
Обычный пользователь ничего не увидел. Почему?

Всё дело в том, что пользователи должны повесить на ядрёный брелок (kernel keyring) свои логин/пароль. Тогда ядро сможет получать с сервера необходимые ресурсы, используя эти данные.

С командной строки это можно сделать утилиткой cifscreds из пакета cifs-utils:

$ cifscreds add -u alef13 -d CORP
Password: P@ssw0rd

В примере выше заданы пароль/логин на домен. Они будут применяться при доступе к любому серверу, входящему в этот домен/рабочую группу.

Можно сделать иначе и указать учётные данные на конкретный сервер:

$ cifscreds add -u alef13 nas.corp.ru
Password: P@ssw0rd

Посмотреть наличие аутентификационных данных (но не их содержимое!) можно командой keyctl из пакета keyutils:

$ keyctl show
Session Keyring
  30364231 --alswrv      0     0  keyring: _ses
 500025711 --alswrv      0 65534   \_ keyring: _uid.0
 497176618 ----sw-v      0     0   \_ logon: cifs:d:CORP
 343241234 ----sw-v      0     0   \_ logon: cifs:a:192.168.0.2

Впрочем, свои учётные данные можно загонять в брелок с помощью команды keyctl (и так даже проще скриптовать):

$ keyctl add logon cifs:d:CORP alef13:P@ssw0rd @s

Или

$ keyctl add logon cifs:a:192.168.0.2 alef13:P@ssw0rd @s

После таких манипуляций картина совершенно другая:

Проверяем, что видит root.
Проверяем, что видит обычный пользователь
Вешаем на брелок наш логин/пароль. Проверили, как висит.
Пользователь имеет доступ! И обратите внимание, что видит он больше, чем рут.

Напрягать пользователя на дополнительный ручной ввод своих учётных данных не хочется, поэтому сделаем, чтобы они вводились автоматом. Если логин/пароль для доступа к ресурсу совпадают с учётными данными, под которыми пользователь авторизуется в системе, то всё решается подключением pam_cifscreds. Для настройки достаточно прочитать соответствующий man. Только не забывайте синхронизировать пароль рабочей учётной записи и пароль на общем ресурсе, иначе можно заблокироваться при безуспешных попытках входа.

Если учётки/пароли не совпадают, то надо создать скрипт, который будет вызываться из папки автостарта вашего Desktop Environment и загонять необходимые парольные пары в ядро при входе пользователя в систему. Это либо простейший bash-скрипт с вызовом keyctl, как я показал выше, либо скрипт на Python.

Для любителей Питона

Чтобы написать скрипт на Python, надо научиться работать с keyring ядра. Штатных библиотек я не нашёл, вроде есть какие-то древние исходники на GitHub, но и они нам не понадобятся.

Для начала подсмотрим, как работает с keyring утилита cifscreds.

alef13 ~ $ strace cifscreds add -u alef13 192.168.0.2 2>&1| grep key
openat(AT_FDCWD, "/lib64/libkeyutils.so.1", O_RDONLY|O_CLOEXEC) = 3
keyctl(KEYCTL_GET_KEYRING_ID, KEY_SPEC_SESSION_KEYRING, 0) = 67942699
keyctl(KEYCTL_GET_KEYRING_ID, KEY_SPEC_USER_SESSION_KEYRING, 0) = 956021303
keyctl(KEYCTL_SEARCH, KEY_SPEC_SESSION_KEYRING, "logon", "cifs:a:192.168.0.2", 0) = -1 ENOKEY (Required key not available)
Password: P@ssw0rd
add_key("logon", "cifs:a:192.168.0.2", "alef13:P@ssw0rd\0", 15, KEY_SPEC_SESSION_KEYRING) = 697036719
keyctl(KEYCTL_SETPERM, 697036719, KEY_POS_VIEW|KEY_POS_WRITE|KEY_POS_SEARCH|KEY_USR_VIEW|KEY_USR_WRITE|KEY_USR_SEARCH) = 0

Видна полезная нагрузка — это подтягивание libkeyutils.so.1 и вызов add_key. Соответствующий сниппет Python-кода:

keyutils = ctypes.CDLL('libkeyutils.so.1')

key_id = b'cifs:a:192.168.0.2'
key_value = b'alef13:P@ssw0rd\0'

n = keyutils.add_key(b'logon', key_id, key_value, len(key_value), -3)
print(n)

Осталось разработать красивую обвязку: проверка/удаление старых ключей, работа с конфигурационными файлами и т. д.

▍ Рецепт 2. Монтирование с аутентификацией kerberos

Штатная опция mount.cifs, отвечающая за метод аутентификации, называется sec, и для kerberos имеет значения krb5 и krb5i. Выбираете подходящий и будете аутентифицироваться при монтировании ресурса с помощью билетика kerberos, лежащего в вашем кэше.

Опять клиенту в /etc/fstab добавляем запись типа:

//srv1/shara1	/mnt/shara1	cifs	domain=CORP,sec=krb5,multiuser,file_mode=0600,dir_mode=0700	0 0

Здесь, по сравнению с «Рецептом 1», ситуация противоположная — входя в систему, пользователь аутентифицируется в домене, и билетик автоматически складывается в кэш kerberos-а, а вот руту этот кэш необходимо пополнить принудительно при старте системы. Для этого мы сделаем простейший сервис, который посредством kinit будет получать билетик при загрузке системы, а чтобы избежать интерактивности (ввод пароля) будем использовать keytab.

Работа с утилитами kerberos это практически отдельная статья, при желании вы найдёте их в интернете в достаточном количестве. Здесь я приведу минимальный набор только лишь для того, чтобы стартануть и потестировать предлагаемый метод монтирования.

Прежде всего необходимо сформировать keytab-файл. Для этого запускаем команду ktutil, и в приглашении вводим следующие заклинания:

# ktutil
ktutil: addent -password -p needly -k 1 -e rc4-hmac
Password for needly@CORP: P@ssw0rd
ktutil: wkt /etc/krb5.keytab
ktutil: q

Кратко по параметрам: -password — аутентификация по паролю, -p needly — «технический» пользователь (principal), который будет логиниться к разделяемому ресурсу, -k 1 — версия записи KVNO (из нескольких идентичных записей будет использоваться с большим номером), -e rc4-hmac — метод шифрования.

Далее авторизуемся, чтобы сгенерировать кэш (заодно протестируем наш keytab).

# kinit -k -V needly
Using default cache: /tmp/krb5cc_0
Using principal: needly@CORP
Authenticated to Kerberos v5

Прошу обратить внимание, что кейтаб наш работает, пока не истёк пароль учётной записи, а также в домене должен существовать пользователь needle с паролем P@ssw0rd.

Итак, кейтаб подготовлен, теперь необходим сервис для обновления кэша kerberos при загрузке системы.

Формируем текстовый файл /etc/systemd/system/root_krb_init.service:

[Unit]
Description=Updating k-ticket root
After=network-online.target

[Service]
ExecStart=/usr/bin/kinit -k -t /etc/krb5.keytab needly

[Install]
WantedBy=remote-fs-pre.target

Далее стандартно:

# systemctl daemon-reload && systemctl enable root_krb_init.service

Перезагружаемся и пробуем:

Пользователь root ничего не видит (просто на этом сервере ему ничего не выдали), но и ошибок никаких нет.
Обычный пользователь ничего не видит (тут я забыл заскриншотить пустой вывод klist), есть ошибки.
Получаем билетик.
Профит!!!

▍ Специи и приправы

Унифицированной точки монтирования и правильного разграничения доступа мы добились, однако внедрять по рабочим местам ещё рановато — надо дать необходимые пояснения и красиво это подать пользователю.

Многие обратили внимание, что изменения вносятся в fstab, а не в модули systemd. Я знаю и умею их писать, однако работа с fstab мне нравится больше — всё в одном месте, редактировать легко, все опции удобны и понятны. Более того, Леннарт Пёттеринг (автор systemd) также рекомендует вносить изменения в /etc/fstab — смотрите man systemd.mount в разделе FSTAB. Там же находятся и опции, позволяющие определить порядок монтирования и другие полезные директивы, используемые в unit-файлах для файловых систем (кстати, в рецепт с собакой необходимо в строчку монтирования ресурса добавить опцию x-systemd.after=root_krb_init.service ).
В примерах строчек для монтирования я указал права на ресурсы — файлы 600, каталоги 700. Система прав Linux (точнее POSIX) довольно примитивна, но и она вызывает затруднения у некоторых товарищей, из которых они выходят простейшим образом — дают на файлы и каталоги права 777. Это ужасно, хоть и работает в большинстве случаев. При таком подходе существует ненулевая вероятность поймать троянского коня, вот примерно такого — «Файлы полиглоты или как картинка с котиком станет угрозой для безопасности вашей информации». Самое опасное — это права выполнения на все файлы. Поэтому рекомендую ставить как я написал выше, про группу и прочих не волнуйтесь — права хоть и будут отображаться, но опция multiuser работает только с пользователями, предоставившими свои учётки для доступа к серверу.
Чтобы смонтированный сетевой ресурс появился на рабочем столе и в файловом менеджере, нам необходимо монтировать их в каталоги /media, $HOME или /run/media/$USER. Если стандартные точки монтирования не нравятся, монтируем куда хочется, только добавляем опцию x-gvfs-show в соответствующую строку fstab, и тогда ресурс также отобразится на десктопе. Дополнительные визуальные параметры описаны здесь what-is-shown.txt.
Если решите опцией x-gvfs-name дать своему ресурсу красивое имя на рабочем столе, то учтите — пробелы в чистом виде использовать не получится, и их не заэкранировать слэшами со всякими кавычками. Просто вместо пробелов и спецсимволов используйте их шестнадцатеричное (x-gvfs-name=my%20cool%20share) представление.
Формирование кэша с помощью kinit — рабочий вариант, но есть и получше. Я имею в виду kstart, который позволяет автоматически продлевать билет и восстанавливать его при обрыве связи. К сожалению, в коробку с РедОС его не положили, поэтому разбирайтесь с ним самостоятельно. Если остаётесь на kinit, то постарайтесь сделать так, чтобы пользователи ежедневно выключали систему.
Когда возникают проблемы — отключайте антивирус В данном случае это хоть и выглядит шуткой, однако при проработке решений он попортил у меня немало крови. Как оказалось, один отечественный антивирус игнорирует исключения путей, внесённые в настройки задач, а ведёт себя адекватно только когда точки монтирования прописаны в глобальные исключения.

▍ Финал

Обозначенные ранее цели достигнуты — это безопасно, унифицировано, прозрачно для любого пользователя, и вдобавок у них одинаковые фиксированные пути к любому сетевому ресурсу. Настройки сделаны удалённо на всех рабочих местах, можно идти к пользователю и показывать красивую иконку диска «R» на рабочем столе. Изначально писал как некую шпаргалку для себя и своих коллег, но надеюсь, и вам этот небольшой туториал поможет немного упростить задачу импортозамещения.

Telegram-канал с розыгрышами призов, новостями IT и постами о ретроиграх ?️

Источник

Смонтировать сетевую папку в Linux с помощью cifs-util

Автоматическое монтирование сетевой папки в Linux

Linux: подключиться к сетевой папке с помощью клиента samba

Подготовка

Установка пакетов

Сетевые порты

Синтаксис

Ручное монтирование

Автоматическое монтирование CIFS через fstab

Примеры использования опций

Версии SMB

Монтирование от гостевой учетной записи

Права на примонтированные каталоги

Читайте также

Why It May Not Work?

Ensure that Everything is Set Up Correctly in Windows

Wrapping Up

Монтируем шары для юзеров

▍ Рецепт 1. Монтирование с логином/паролем

▍ Рецепт 2. Монтирование с аутентификацией kerberos

▍ Специи и приправы

▍ Финал