Я пытаюсь подключить клиент под управлением Ubuntu 13.04 к сетевому ресурсу, размещенному на файловом сервере, который недавно был обновлен с Windows Server 2003 до 2012.
В настоящее время я могу смонтировать удаленный общий ресурс, подключившись к локальной сети, используя:
sudo mount -t cifs //myserver.mydomain.co.uk/myshare /media/myshare/ -o user=myself,domain=myworkgroup,pass=**********
Однако у меня возникли проблемы с монтированием общего ресурса через Cisco (IPsec/Xauth) VPN. До обновления сервера у меня не было с этим проблем, но теперь я получаю следующее сообщение:
mount error(112): Host is down
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
dmesg | tailдает мне[ 1975.651346] CIFS VFS: cifs_mount failed w/return code = -112
Хост определенно не отключен — я все еще могу подключиться к тому же ресурсу через VPN, используя smbclient:
smbclient //myserver.mydomain.co.uk/myshare -U myself -W myworkgroup
Enter myself's password:
session request to MYSERVER.MYDOMAIN failed (Called name not present)
Domain=[MYWORKGROUP] OS=[Windows Server 2012 Standard 9200] Server=[Windows Server 2012 Standard 6.2]
smb: \>
Я не уверен в значимости session request to MYSERVER.MYDOMAIN failed (Called name not present)ошибки " ", так как я все еще могу просматривать структуру каталогов.
Есть ли у вас предложения, что можно попробовать дальше?
решение1
Вы можете подключиться с помощью SMB Client, поскольку вы можете подключиться как "анонимный". Но возможность подключиться как анонимный не означает, что служба аутентификации для обычных пользователей работает.
У вас, вероятно, проблема с брандмауэром. Откройте эти 4 порта:
- UDP&TCP/137
- UDP&TCP/138
- UDP&TCP/139
- TCP/445
Убедитесь, что вы также разрешаете взаимодействовать службе Netlogon на стороне Windows.
решение2
Можете ли вы получить доступ к порту 445/tcp при подключении через VPN. Используйте
nc -v myserver.mydomain.co.uk 445.
Если бы это сработало.
Connection to myserver.mydomain.co.uk 445 port [tcp/microsoft-ds] succeeded!
Единственная проблема, которую вы можете увидеть, это если брандмауэр проксирует соединение, которое может быть успешно установлено в любом случае. Тогда вам нужно будет сделать захват пакетов и посмотреть, отправляет ли сервер Windows что-либо.
решение3
И вот, год спустя я наконец понял это!
Корневая причина оказалась в проблеме с разрешением имени хоста. Подсказка пришла, когда я пытался решить другую проблему с SSHing на машине в той же удаленной сети через VPN.
Из вывода ssh -v:
debug1: Connecting to myserver2.mydomain.ox.ac.uk [163.1.21.182] port 22.
Я обнаружил, что OpenSSH пытался подключиться к бессмысленному IP-адресу (на самом деле он преобразовывал имя хоста моего сервера в IP-адрес сетевого принтера!). Я обнаружил, что это pingтакже не позволяло правильно преобразовывать имена хостов, тогда какhost казалось, работает. Это в конечном итоге привело меня кэта темана Ask Ubuntu.
Оказывается, pingи sshоба используют glibc resolver, как и mount.cifs. Источники, из которых glibc получает информацию о службе имен, настраиваются в/etc/nsswitch.conf.
Первоначально содержимое моего письма nsswitch.confвыглядело так:
passwd: compat
group: compat
shadow: compat
hosts: files myhostname mdns4_minimal [NOTFOUND=return] dns wins mdns4
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis
Важная строка начинается с hosts:, в которой перечислен порядок источников, которые glibc запрашивает при выполнении разрешения имени хоста. Обратите внимание, что в моей версии dnsидет после [NOTFOUND=return]в порядке поиска.
Я интерпретирую так: если glibc не сможет разрешить имя хоста в соответствии с первыми четырьмя источниками, он вернется до того, как фактически запросит какие-либо DNS-серверы! Я понятия не имею, почему это nsswitch.confбыло настроено таким образом (я определенно не настраивал это таким образом), но изменение строки на:
hosts: files myhostname mdns4_minimal dns [NOTFOUND=return] wins mdns4
внезапно заставил все работать правильно, включая ping, sshи mount.cifs.