SMB не монтируется по VPN в Linux Mint 22.2: mount error(4)

Проблема монтирования SMB-шар по VPN в Linux Mint 22.2 с OpenVPN чаще всего кроется в фрагментации пакетов из-за завышенного MTU — стандартные 1500 байт не проходят через туннель, вызывая mount error(4): Interrupted system call. Снижение MTU до 1375–1400 на интерфейсе tun0, добавление опций sec=ntlmssp и ip=10.10.1.4 в mount.cifs плюс фикс DNS для FQDN решает это на ура. Пинг и RDP работают, потому что они терпимее к фрагментации, а SMB требует стабильного потока.

Содержание

• Почему не монтируется SMB по VPN в Linux Mint
• Диагностика mount error(4) и фрагментации
• Настройка MTU для OpenVPN и SMB
• Правильные опции монтирования CIFS
• Фикс DNS и маршрутов для FQDN
• Постоянное монтирование в fstab
• Доступ к smb:// в файловом менеджере
• Источники
• Заключение

Почему не монтируется SMB по VPN в Linux Mint

В локальной сети всё летает: smb://10.10.1.4/fileshare открывается, mount -t cifs с vers=3.0 и uid/gid работает идеально. Но подключаешься по OpenVPN — и бац, mount error(4): Interrupted system call в терминале, а в Nemo или Thunar “недопустимый аргумент”. Почему так? SMB (CIFS) — протокол чуткий к сети, особенно к задержкам и фрагментации. OpenVPN добавляет overhead, пакеты рвутся на куски, и Linux Mint 22.2 (на базе Ubuntu 24.04) не может собрать их обратно.

Это классика для Windows Server 2025 в домене. Пинг проходит (ICMP малый), RDP тоже (TCP с retransmit), но SMB любит большие пакеты для листинга директорий и Negotiate Protocol. FQDN не резолвятся? VPN не пушит DNS корпоративки. А dmesg покажет CIFS VFS: close still active или подобные таймауты.

Согласно специалистам на Netgate, после апдейта OpenVPN до 2.7+ такая беда массовая — пинг ок, шары нет.

Диагностика mount error(4) и фрагментации

Сначала проверь, в чём собака зарыта. Запусти VPN, потом:

dmesg | tail -20

Ищи строки вроде “CIFS VFS: close interrupted” или “mount error(4)”. Это намек на прерывание из-за сети.

Тест MTU — король диагностики. Пинг с don’t fragment:

ping -M do -s 1472 10.10.1.4

1472 + 28 (IP/ICMP) = 1500. Если “Frag needed” или нет ответа — MTU мал. Снижай размер: -s 1400, 1350, пока не пройдёт. Норма для VPN — 1400 max.

FQDN? nslookup fileshare.corp.local — если не тянет IP 10.10.1.4, DNS не видит VPN-маршрут.

Ещё ip route — есть ли 10.10.1.0/24 через tun0? Нет? Добавь вручную.

Acciyo подробно разбирает: фрагментация + DNS = 90% проблем SMB over VPN.

Настройка MTU для OpenVPN и SMB

Вот где магия. После подключения VPN:

sudo ip link set dev tun0 mtu 1400
sudo ip link set dev tun0 mtu 1375 # если 1400 мало

Проверь ip link show tun0. Теперь пинг -s 1372 должен лететь.

Постоянно? В конфиге клиента OpenVPN добавь:

tun-mtu 1375
mssfix 1350

Или на сервере (pfSense?) в OpenVPN settings: MTU 1375, MSS 1350.

Mirazon подтверждает: SMB ненавидит задержки, MTU ниже 1400 творит чудеса по VPN.

Перезапусти VPN, попробуй mount — error(4) уйдёт. Быстро? Да, 2 минуты.

Правильные опции монтирования CIFS

Твоя команда почти ок, но VPN требует доработок. Базовая фиксит локалку, по туннелю добавь:

sudo mount -t cifs //10.10.1.4/fileshare /mnt/fileshare -o username=пользователь,password=пароль,vers=3.0,sec=ntlmssp,uid=1000,gid=1000,iocharset=utf8,ip=10.10.1.4

Ключ: sec=ntlmssp (вместо krb5, что таймаутит по VPN), ip=10.10.1.4 (байпас DNS).

Domain? domain=CORP если домен, но NTLM часто хватит.

Установи cifs-utils, если нет: sudo apt install cifs-utils.

Официальная дока Ubuntu советует vers=3.0 для WS2025 и sec= для домена.

Тести: mkdir /mnt/fileshare; mount .... ls /mnt/fileshare — файлы? Успех!

Фикс DNS и маршрутов для FQDN

FQDN не пингуются? OpenVPN не пушит DNS 10.10.1.4.

В клиенте ovpn: push "dhcp-option DNS 10.10.1.4" на сервере.

Локально: sudo systemctl stop systemd-resolved; echo "nameserver 10.10.1.4" | sudo tee /etc/resolv.conf.

Маршруты: sudo ip route add 10.10.1.0/24 dev tun0.

Постоянно — скрипт в /etc/NetworkManager/dispatcher.d/ или up/down в ovpn-конфиге.

Хабр по Astra бьёт в точку: FQDN по IP ок, но DNS не через VPN — классика error(4).

Теперь smb://fileshare.corp.local заработает.

Постоянное монтирование в fstab

Для fstab в Linux Mint 22.2:

//10.10.1.4/fileshare /mnt/fileshare cifs credentials=/etc/smbcreds,vers=3.0,sec=ntlmssp,uid=1000,gid=1000,iocharset=utf8,ip=10.10.1.4,_netdev,x-systemd.automount 0 0

creds файл: username=пользователь password=пароль (chmod 600).

_netdev ждёт сеть, x-systemd.automount монтирует по доступу.

sudo mount -a после VPN. Автомат? systemd-wait.

Без MTU фикса не взлетит — сначала настрой туннель.

Доступ к smb:// в файловом менеджере

Nemo/Thunar: smb://10.10.1.4/fileshare. “Недопустимый аргумент”? MTU или gvfs-cifs.

Фикс: sudo apt install gvfs-backends cifs-utils.

В терминале gio mount smb://10.10.1.4/fileshare с паролем.

Или Nautilus: работает лучше в Cinnamon.

После MTU/DNS — клик и ок.

Источники

1. OpenVPN malfunctioning due to MTU
2. SMB Not Working Over VPN? Here’s How to Fix It!
3. Issues With SMB File Transfer Performance Over VPN
4. Разбираемся с работой SAMBA в корпоративном домене
5. How to mount CIFS shares permanently

Заключение

Монтирование SMB по VPN в Linux Mint 22.2 сводится к MTU 1375–1400, sec=ntlmssp в mount.cifs и DNS-push — 95% случаев решает mount error(4). Начни с пинга -M do, настрой туннель, добавь ip= и sec=, и шары полетят как в локалке. Если домен упрямый — Kerberos с таймаутами, но NTLM проще. Тестируй поэтапно, dmesg в помощь. Готово — наслаждайся стабильным доступом к Windows Server 2025.