Как я могу диагностировать отказ входа в систему SMB NAS?

Так как вопрос о диагностике, а не возможном решении, я опишу вещи, которые я попробовал, который получил меня ближе к решению (обновления в вопросе суммируют большую часть из него).

При чтении вывода команды ниже, обратите внимание, что мой NAS называют giles и доменное имя SUNNYDALE. Мое локальное имя пользователя, и который на поле jason. Я установил тестовый пароль abcd для этого.

Спойлер: это был метод аутентификации.

Проблема состояла в том, что NAS управляет, только, кажется, работает когда NTLM аутентификация используется из Ubuntu; большая часть использования утилит NTLMv2 по умолчанию или некоторый вариант этого. Я был загнан в угол тем, что начальные инструменты, которые я использовал, не позволяли мне управлять этим.

Не дайте спать полю

Большинство корпусов NAS помещает диск спать после периода неактивности. Обычно это - хорошая вещь, но во время диагностики она может вызвать побочные ошибки с определением имен или аутентификацией в зависимости от используемых инструментов.

Отключите sleep-when-idle опцию, в то время как Вы отлаживаете, или сохраняете веб-интерфейс открытым в браузере и периодически обновляете его, чтобы удостовериться, что он произошел. Не забудьте повторно включать его, когда Вы будете сделаны!

Удостоверьтесь, что можно разрешить его

Сначала удостоверьтесь, что можно разрешить NAS. Использовать nmblookup:

~ • nmblookup giles
192.168.1.114 giles<00>

Если Вы не видите его, Вы, возможно, должны были бы установить libnss-winbind пакет (т.е. с sudo apt-get install libnss-winbind) и редактирование /etc/nsswitch.conf. Ищите начало строки hosts: и место wins где-нибудь:

hosts:          files mdns4_minimal [NOTFOUND=return] dns wins mdns4

(Обратите внимание, что я не эксперт по этим настройкам; запишите то, чем строка была прежде в случае, если Вы работаете в обеспокоиться позже.)

Используйте mount.cifs, не smbclient

Я нашел это smbclient не поймал мою проблему, потому что она не позволяет Вам подстраивать настройки аутентификации. mount.cifs утилита делает, как бы то ни было. Существует несколько других деталей, это дает Вам больше контроля, например, используемую версию протокола SMB. Этот терминальный сеанс показывает, как можно попробовать различные домены и методы аутентификации:

~ • mkdir temp
~ • sudo mount.cifs //giles/jason ./temp -o username=jason,password=abcd,domain=SUNNYDALE
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
~ • sudo mount.cifs //giles/jason ./temp -o username=jason,password=abcd,domain=SUNNYDALE,sec=ntlmv2
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
~ • sudo mount.cifs //giles/jason ./temp -o username=jason,password=abcd,domain=SUNNYDALE,sec=ntlm
~ •

(Что последняя команда была успешна.)

Обратите внимание, что Вы могли бы получить некоторые побочные отказы от mount.cifs хотя, например:

~ • sudo mount.cifs //giles/jason ./temp -o username=jason,password=abcd,domain=SMB
mount error: could not resolve address for giles: Unknown error
~ • sudo mount.cifs //giles/jason ./temp -o username=jason,password=abcd,domain=SMB
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

Иногда я даже получал ошибку аутентификации на первой попытке, но не следующем. Попробуйте каждую команду два или три раза, чтобы быть уверенными.

Переопределите smb.conf значения по умолчанию настроек/инструмента

Будьте осторожны при отладке проблем SMB, в которых Вы не полагаетесь на значения по умолчанию также /etc/samba/smb.conf или mount.cifs (или безотносительно инструмента Вы используете). В частности, рабочая группа (запуск строки workgroup =) и метод аутентификации (client ntlm auth = ... например, с несколькими строками для различных протоколов).

Отметьте это в mount.cifs терминальный сеанс выше, я всегда указываю домен при изменении метода аутентификации. Будьте научными! Измените одну и только одну вещь каждый раз. Если это становится утомительным, запишите сценарий!

Попробуйте различные рабочие группы

Как Ben Grimm указывает, иногда эти поля игнорируют рабочую группу, которую Вы даете им. Попробуйте одно из следующего:

• РАБОЧАЯ ГРУППА
• SMB

Найдите машина OS X или Windows

Это - основная проверка работоспособности: если можно соединиться из Windows или машины Mac, должно, по крайней мере, быть возможно (даже если трудный) соединиться из Ubuntu. Если Вы не можете соединиться ни от какой другой машины, вернитесь к запуску и попытайтесь настроить вещи, пока Вы не можете.

В моем случае у меня не было машины не-Linux для попытки сначала. В конечном счете я нашел старый XP VM (это было резервное копирование машины от несколько лет назад). Я понял, что мог соединиться с NAS очень хорошо от него! Это привело меня к моей следующей тактике …

Wireshark

Wireshark является программой, которая осматривает и выводит пакеты, проходящие интерфейс на Вашем компьютере. После того как я понял, что мой VM XP мог соединиться, это стало вопросом выяснения, что делала та машина, та моя машина Ubuntu не была.

Wireshark только контролирует интерфейсы на компьютере, на нем работают. Это означает, что необходимо выполнить его на машине, которая находится промежуточная тестовые машины и поле NAS. Я не собираюсь давать полное учебное руководство при маршрутизации и т.д. здесь, но она работала на меня, потому что я выполнил ее на машине, размещающей VM XP, таким образом, все пакеты проходили eth0 насколько Wireshark был заинтересован.

В моем случае VM XP имел IP 192.168.1.111 и NAS имел IP 192.168.1.114. Таким образом, фильтр получения, который я использовал в Wireshark, был:

(host 192.168.1.111) and (host 192.168.1.114)

Затем я:

• загруженный VM XP
• запущенный получение
• в VM XP я запустил Проводник, вводимый \\giles\jason и хит входит
• вводимый мои учетные данные и домен
• после того как доля была открыта, я переключился назад на Wireshark и остановил получение.

На данном этапе я просмотрел пакеты при помощи Edit > Find packet... и выбор "строкой" опция. Я просто искал свое имя пользователя и искал первую попытку успешной аутентификации. Вы видите, которые неудачны путем поиска STATUS_LOGON_FAILURE несколько пакетов позже.

То, что удивило меня, было чистым количеством попыток, которые выполнял XP. Это использовало данное имя пользователя и доменное имя, иногда это использовало WORKGROUP или SMB или даже имя клиента как домен, и это попробовало несколько методов аутентификации.

Странно достаточно я даже не определил успешную попытку! Это было точкой, в которой я понял smbclient движение не должно было помогать и вернулось к mount.cifs и используемый это намного более с научной точки зрения.

Примечание о NTLM и Nautilus/GVFS

Наконец, после выяснения, через что проблема была и успешно доступ к доле mount.cifs, Я все еще не мог заставить Наутилус соединяться. Проблемой здесь является использование Наутилуса GVFS для монтирования долей SMB и использования GVFS NTLMv2 по умолчанию.

Можно изменить это в масштабе всей системы путем редактирования /etc/samba/smb.conf и добавление:

   client ntlm auth = yes
   client ntlmv2 auth = no

Я добавил это чуть ниже workgroup = ... установка. Однако это вызовет изменение для всех долей SMB, которые GVFS пыталась смонтировать, который мог бы сделать другие доли недоступными, поэтому остерегаться.

(По некоторым причинам mount.cifs жалуется на ту первую строку, но testparm не делает. Возможно, это может быть удалено, но я не игра для попытки.)