[{"content":"Симптомы Часть DFS-шар на Linux-хостах (монтирование через autofs + mount.cifs) перестала монтироваться после переноса части нод файлового кластера в другой сегмент сети. Ошибка в dmesg: CIFS: VFS: Error connecting to socket. Aborting operation. CIFS: VFS: cifs_mount failed w/return code = -115 Падают не все шары, а только определённые — те, чьи данные физически лежат на перенесённых нодах. Параметры монтирования (vers=, uid=, gid=, credentials= и т.д.) у рабочих и нерабочих шар идентичны. smbclient -L и ручное подключение к серверу проходит нормально. Полная перезагрузка Linux-хоста временно решает проблему для конкретного сервера, но не является решением — на другом идентичном хосте без перезагрузки проблема сохраняется сколь угодно долго. Ход диагностики Код -115 = таймаут на уровне сокета при попытке установить TCP-соединение. Это не ошибка авторизации (в отличие от -13 = EACCES).\nПошагово были исключены следующие гипотезы:\nDNS-резолвинг — getent hosts / dig показывали корректный, актуальный адрес. Не причина. ARP-кэш — ip neigh flush all не помог. Не причина. Kernel keyring (dns_resolver / cifs.upcall) — keyctl clear @s / @u не помог. Не причина. /proc/fs/cifs/dfscache — сброс не помог. Не причина. /etc/samba/lmhosts — файл пуст. Не причина. /proc/fs/cifs/DebugData — показывал Servers: [NONE], то есть резидентных сессий в ядре нет, резолвинг идёт заново при каждой попытке — и всё равно упирается в старый адрес. umount -a -t cifs + rmmod cifs + modprobe cifs — не помогло (см. ключевую находку ниже). Как нашли реальную причину strace -f -tt на mount.cifs показал прямой вызов ядра:\nmount(\u0026#34;//corp.example.internal/Workgroups/Operations\u0026#34;, \u0026#34;.\u0026#34;, \u0026#34;cifs\u0026#34;, MS_NOSUID, \u0026#34;ip=10.76.128.24,unc=\\\\\\\\corp...\u0026#34;) = -1 EINPROGRESS (10.427507 сек, затем -115) mount.cifs резолвит DFS-namespace в адрес контроллера домена — и это соединение к DC проходит нормально (порт 445 открыт, smbclient подключается без проблем).\nВключение подробного debug-лога CIFS-модуля в ядре:\necho 7 \u0026gt; /proc/fs/cifs/cifsFYI echo 1 \u0026gt; /proc/fs/cifs/traceSMB dmesg -T | tail -100 показало суть:\nCIFS: Status code returned 0xc0000257 STATUS_PATH_NOT_COVERED Это стандартный SMB-статус: путь находится в DFS-пространстве, обратитесь за referral. После него клиент:\nОтправляет TRANS2 GET_DFS_REFERRAL запрос к DC. Получает от DC ответ с реальным IP файлового сервера-таргета. Разрывает сессию с DC (Tree Disconnect) и пытается подключиться к таргету. Таргет оказывается старым, уже неактуальным IP-адресом ноды — до переноса эта нода была там, сейчас у неё другой адрес. Соединение виснет 10 секунд (таймаут) → -115. Подтверждено через tcpdump + tshark:\ntshark -r dump.pcap -Y \u0026#34;ip.addr==\u0026lt;DC_IP\u0026gt; || ip.addr==\u0026lt;target_ip\u0026gt;\u0026#34; \\ -T fields -e frame.number -e ip.src -e ip.dst -e smb2.cmd Видна последовательность: IOCTL (cmd=11, DFS referral request) → Tree Disconnect → появление старого адреса таргета в трафике.\nКорневая причина DFS-referral, который отдают некоторые контроллеры домена, обслуживающие namespace, продолжал указывать на старый (уже неактуальный) IP ноды после её физического переноса. Это не проблема клиента, DNS, ARP или любого клиентского кэша — DC сам возвращает устаревший адрес в ответ на FSCTL_DFS_GET_REFERRAL.\nВозможные причины на стороне DFS/AD:\nTarget в DFS Folder (Get-DfsnFolderTarget) не обновили при переносе ноды. Referral-кэш конкретных DC (у каждого DC свой независимый кэш с TTL, обычно TargetListCacheLifetime ~30 мин) ещё не сброшен (dfsutil /pktflush выполняется на самом DC, а не на клиенте). DC несколько, и клиент \u0026ldquo;прилипает\u0026rdquo; к одному из них (DC locator/affinity) — разные хосты и попытки монтирования могли получать referral от разных DC: часть уже с актуальными данными, часть ещё нет. Этим объясняется, почему на одном хосте помогла перезагрузка (клиент заново выбрал DC и попал на \u0026ldquo;свежий\u0026rdquo;), а на другом — нет. Почему не помогали стандартные шаги на клиенте Действие Результат Почему rmmod cifs + modprobe cifs не помогло rmmod выгружает только сам модуль, не трогая зависимости (например dns_resolver), в которых, вероятно, и сидело резидентное состояние modprobe -r cifs + modprobe cifs помогло modprobe -r выгружает модуль вместе со всеми неиспользуемыми зависимостями — полностью сбрасывает состояние, аналогично тому, что происходит при reboot Полная перезагрузка хоста помогало, но нестабильно Сбрасывает всё состояние клиента, включая выбор DC — при повторном резолвинге клиент может попасть на другой (уже обновившийся) DC. По сути — \u0026ldquo;повезло с выбором\u0026rdquo;, а не системное решение Итоговое решение sudo modprobe -r cifs # НЕ rmmod! sudo modprobe cifs Без необходимости перезагружать весь сервер.\nКлючевой момент: rmmod cifs ≠ modprobe -r cifs. rmmod выгружает только указанный модуль. modprobe -r выгружает модуль и все его неиспользуемые зависимости (аналог apt autoremove для модулей ядра) — именно в зависимости, судя по всему, и залипало состояние DFS/DNS-резолвинга. Что нужно поправить на стороне DFS/AD При следующем переносе DFS-нод в другой сегмент сети сообщать администраторам AD/DFS заранее:\nПроверить/обновить target в DFS Folder до переноса: Get-DfsnFolderTarget -Path \u0026#34;\\\\corp.example.internal\\Workgroups\\\u0026lt;Share\u0026gt;\u0026#34; Set-DfsnFolderTarget ... После обновления конфигурации — принудительно сбросить referral-кэш на всех DC, обслуживающих namespace: dfsutil /pktflush Проверить репликацию DFS-конфигурации между контроллерами домена (repadmin /replsummary), чтобы исключить рассинхрон между DC. Шпаргалка команд # Посмотреть активные CIFS-сессии в ядре cat /proc/fs/cifs/DebugData # Включить подробный debug CIFS-модуля echo 7 \u0026gt; /proc/fs/cifs/cifsFYI echo 1 \u0026gt; /proc/fs/cifs/traceSMB dmesg -T | tail -100 echo 0 \u0026gt; /proc/fs/cifs/cifsFYI # Сбросить DFS-кэш ядра echo 0 | sudo tee /proc/fs/cifs/dfscache # Правильная выгрузка модуля со всеми зависимостями sudo modprobe -r cifs sudo modprobe cifs # strace на попытку монтирования strace -f -tt -o /tmp/trace.log mount -t cifs //server/share /mnt/test -o credentials=... grep -E \u0026#34;connect|mount\\(\u0026#34; /tmp/trace.log # Захват трафика + разбор SMB2 команд sudo tcpdump -i \u0026lt;iface\u0026gt; -n port 445 -w /tmp/dump.pcap tshark -r /tmp/dump.pcap -Y \u0026#34;smb2\u0026#34; -T fields -e frame.number -e ip.src -e ip.dst -e smb2.cmd # cmd 11 = IOCTL (в т.ч. DFS referral request), cmd 4 = Tree Disconnect # Проверить SMB-доступность конкретного сервера напрямую (в обход DFS) smbclient -L //\u0026lt;ip\u0026gt; -U \u0026#39;DOMAIN\\user\u0026#39; smbclient //\u0026lt;ip\u0026gt;/\u0026lt;share\u0026gt; -U \u0026#39;DOMAIN\\user\u0026#39; -c \u0026#39;ls\u0026#39; ","permalink":"https://notes.alchi.ru/posts/dfs-cifs-mount-troubleshooting/","summary":"Разбор реального инцидента: часть DFS-шар перестала монтироваться на Linux-хостах после переноса нод в другой сегмент сети. Код -115, strace, tcpdump, tshark и неожиданная разница между rmmod и modprobe -r.","title":"CIFS/DFS: шары не монтируются после переноса нод файлового кластера в другой сегмент сети"}]