Ошибка подключения к SMB-ресурсу из Docker-контейнера Debian из-за неправильного пароля.

Вопрос или проблема

  ntlm_password_check: NTLMv2 проверка пароля не удалась [2025/01/27 19:23:14.640615,  3] ../../libcli/auth/ntlm_check.c:487(ntlm_password_check)   ntlm_password_check: НИ

  #Мой файл compose:
    ...
        volumes:
    ...
          - originals:/usr/src/app/originals 
    ...
    volumes:
      model-cache:
      originals:
        driver_opts:
          type: cifs
          o: 'iocharset=utf8,username=user1,password=passw1,rw' 
          device: '//192.168.10.10/user1'
    ...

Ответ или решение

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

Теория

Монтирование SMB-шар на основе протокола CIFS (Common Internet File System) требует установления успешного сеанса аутентификации между клиентом и сервером. В данном случае клиент — это ваш Docker-контейнер на базе Debian, а сервер — TrueNAS Scale, предоставляющий Samba-шар. Протокол аутентификации, используемый в данном сценарии — NTLMv2 (NT LAN Manager версия 2), который в большинстве случаев обеспечивает безопасный обмен аутентификационными данными.

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

Пример

Рассмотрим, как может быть инициирована ошибка:

1. Неверная кодировка строки: возможно, пароль, указанный в docker-compose файле, подвергся преобразованию или кодировке, из-за чего в виде строки он передается неверно.

2. Неправильная передача переменных окружения: если буквы username и password пересылаются как переменные окружения Docker, убедитесь, что они корректно передаются в контейнер.

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

Применение

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

1. Проверка файловой системы и кодировки:

   • Убедитесь, что ваш docker-compose файл сохранен в правильной кодировке (например, UTF-8). Неверная кодировка документа может исказить пароли при интерпретации.

2. Отладочные переменные и ведение лога:

   • Включите максимальную детализацию логов на стороне TrueNAS и в Docker-контейнере. Это может помочь заметить, в какой именно момент временной линии возникает разрыв в аутентификации.

3. Погружение в контейнер:

   • Используйте docker exec -it <container_id> /bin/bash, чтобы войти в контейнер и попытаться выполнить подключение руками с помощью smbclient. Это позволит подтвердить, что внутри контейнера всё работает корректно.

4. Анализ и тестирование базовой конфигурации:

   • Проверьте, можете ли вы временно использовать другие варианты аутентификации или упростить настройки на стороне TrueNAS, чтобы исключить фактор серверной конфигурации. Например, разрешите LM и NTLM (устаревшие протоколы), чтобы проверить, не повлияло ли это на ваш исходный сценарий.

5. Перепроверка driver_opts:

   • Убедитесь в правильности параметров, передаваемых в разделе driver_opts. Вероятно, использование кавычек, лишние пробелы или неправильное указание параметров могли исказить их сохранение в системе Docker.

6. Тестирование альтернативных методов:

   • Если такая возможность имеется, попробуйте использовать другую машину/окружение для монтирования ресурса стандартным утилитами Linux, например, mount.cifs.

7. Оптимизация настроек безопасности:

   • Обратите внимание