ошибка монтирования 13 = Отказано в доступе

45

Один из моих серверов настроен на автоматическое монтирование каталога Windows с помощью fstab. Однако после последней перезагрузки он перестал работать. Строка в fstab:

//myserver/myfolder /mnt/backup cifs credentials=home/myfolder/.Smbcredentials

.SmbcredentialsФайл:

username=myaccount
password=mypassword
domain=mydomain

Я делаю, mount -aи я получаю mount error 13 = Permission denied. Если я сделаю это достаточно, он заблокирует мою учетную запись Windows, поэтому я знаю, что она пытается. Я проверил, что мой пароль правильный.

Что я делаю не так?

Соленый огурец
источник
4
Не могли бы вы попробовать смонтировать из командной строки mount -t cifs //myserver/myfolder /mnt/backup --verbose -o credentials=home/myfolder/.Smbcredentialsи добавить отладочную информацию (очищенную) к вашему вопросу?
BSD
Какой дистрибутив и версию cifs-utilsвы установили? У меня была эта проблема раньше, и я думаю, что это было связано с обновлением.
SLM

Ответы:

44

Несколько вещей, чтобы проверить. Я делаю нечто подобное, и вы можете протестировать монтирование напрямую, используя mountкоманду, чтобы убедиться, что все настроено правильно.

Разрешения на файл учетных данных

Убедитесь, что этот файл разрешен правильно.

$ sudo ls -l /etc/smb_credentials.txt 
-rw-------. 1 root root 54 Mar 24 13:19 /etc/smb_credentials.txt

Многословное крепление

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

$ sudo mount -v -t cifs //server/share /mnt \
    -o credentials=/etc/smb_credentials.txt

Результатом этого вывода, если он работает:

mount.cifs kernel mount options: ip=192.168.1.14,unc=\\server\share,credentials=/etc/smb_credentials.txt,ver=1,user=someuser,domain=somedom,pass=********

Проверьте логи

После выполнения вышеупомянутой команды монтирования загляните в свои файлы dmesgи / /var/log/messagesили на /var/log/syslogналичие сообщений об ошибках, которые могли быть сгенерированы при попытке mount.

Тип безопасности

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

Я подозреваю, что вы упускаете возможность sec=.... В частности, один из этих вариантов:

   sec=
       Security mode. Allowed values are:
       ·   none - attempt to connection as a null user (no name)
       ·   krb5 - Use Kerberos version 5 authentication
       ·   krb5i - Use Kerberos authentication and forcibly enable packet 
           signing
       ·   ntlm - Use NTLM password hashing
       ·   ntlmi - Use NTLM password hashing and force packet signing
       ·   ntlmv2 - Use NTLMv2 password hashing
       ·   ntlmv2i - Use NTLMv2 password hashing and force packet signing
       ·   ntlmssp - Use NTLMv2 password hashing encapsulated in Raw NTLMSSP
           message
       ·   ntlmsspi - Use NTLMv2 password hashing encapsulated in Raw 
           NTLMSSP message, and force packet signing

       The default in mainline kernel versions prior to v3.8 was sec=ntlm. 
       In v3.8, the default was changed to sec=ntlmssp.

Вы , возможно , потребуется настроить sec=...параметр так , что это либо sec=ntlmили sec=ntlmssp.

Ссылки

SLM
источник
1
Проверка dmesgбыла очень полезной. Этот ответ был с 2014 года, и с тех пор использование WannaCry SMB1.0 сделало его устаревшим, поэтому обязательно добавьте vers=2.0или 2.1, или 3.0, независимо от того, что сервер поддерживает, так как значение по умолчанию 1.0 больше не будет поддерживаться.
Майкл Плаутц
1
Просто наперед: поскольку папка назначения находится под Windows, что часто требует смены пароля время от времени, пароль в файле учетных данных может быть недействительным. mountКоманда не скажет вам такие детали.
ХунбоЖу
22

Спасибо, но еще поиск в Google нашел решение. Он использовал неправильный тип безопасности по умолчанию; эта команда сработала:

$ sudo mount -t cifs //172.16.1.5/myshare/ /mnt/myshare \
    -osec=ntlmv2,domain=MYDOMAIN,username=myusername,password=mypassword
Соленый огурец
источник
Это было! Работа mount -t cifs //10.0.0.138/usb1_1 /mnt/usbdisk -ousername=theusername,password=thepassord,file_mode=0644,dir_mode=0755,uid=rootна машине Fedora 25 работала нормально, но не удалась, когда я выполнил ту же самую команду на коробке openwrt (Chaos Calmer 15.05.1). Добавление sec=ntlmv2заставило это работать там также.
Хловдал
2
Пришел сюда, пытаясь смонтировать член Debian 9 AD от не-члена CentOS 6, и это сблизило меня - в моем случае волшебство былоsec=ntlmssp
Cheetah
Для меня исправлением было использование domainключевого слова и указание его отдельно от имени пользователя.
Джим Фелл
У sec = ntlmv2 есть опция, которая мне нужна для доступа к smb из Ubuntu 18.04 в Windows 10. Спасибо, Пикл.
Ноэль Ай
12

Я столкнулся с этой проблемой, и проблема оказалась не форматирование значений в моем файле учетных данных правильно. Я пытался:

username=DOMAIN\mylogin
password=<password>
domain=FULLY.QUALIFIED.DOMAIN

Я также попробовал:

username=myemailaddress@someplace.com
password=<password>
domain=FULLY.QUALIFIED.DOMAIN

А также:

username=FULLY.QUALIFIED.DOMAIN\mylogin
password=<password>
domain=FULLY.QUALIFIED.DOMAIN

Однажды я только использовал свое имя пользователя для входа в систему:

username=mylogin
password=<password>
domain=FULLY.QUALIFIED.DOMAIN

Я был в состоянии заставить мою гору CIFS преуспеть.

Марк Солсбери
источник
отличное объяснение!
Дима Литуев
2

Это дополнение работает на научной Linux 6.6 (RedHat 6.6)

изменить /etc/fstab
создать файл = .credentials(например, в /etc) с этими деталями:

username=value
password=value
domain=value

//SERVER/SHARE1 /mnt/SHARE1 cifs credentials=/etc/.credentials,rw,uid=1000,gid=1000,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777 0 0 
stoferontheweb
источник
Для меня решены флаги file_mode и dir_mode! :)
Рафаэль Мони