В этом руководстве мы покажем вам шаги по исправлению невозможности смонтировать хранилище в TWRP Recovery. Экосистема Android, благодаря своей природе с открытым исходным кодом, допускает множество настроек.
Единственное требование — разблокировать загрузчик устройства. Как только вы этого добьетесь, вы сможете запустить множество пользовательских двоичных файлов, модов, пользовательских ПЗУ и даже Magisk для рутирования вашего устройства. Однако стандартное восстановление не может установить эти файлы. Вам нужно будет установить кастомное рекавери, например TWRP.
После того, как ваше устройство загрузится в это восстановление, вы можете стереть различные разделы устройства, выполнить резервное копирование Nandroid и, конечно, прошить вышеупомянутые файлы. Однако несколько раз вы можете столкнуться с ошибкой или двумя.
Среди них самые распространенные и пугающие, похоже, не могут смонтировать ошибку хранилища при отображении TWRP. В этом руководстве мы рассмотрим различные причины этой ошибки, а затем перечислим возможные исправления для исправления этой ошибки. Следуйте.
Первая причина, по-видимому, связана с тем, что внутреннее хранилище вашего устройства зашифровано. В результате TWRP не может расшифровать его на ходу и, следовательно, не может получить доступ к файлам, хранящимся на вашем устройстве.
Это причина, по которой эта ошибка чаще всего возникает, когда вы собираетесь прошить файл с помощью этого восстановления.
В других случаях ваш раздел данных может быть поврежден из-за того, что мигает неправильный файл или файл в неправильном разделе. Во всех этих сценариях ваш TWRP может отображать внутреннее хранилище как имеющее 0 МБ занятого места.
Но не волнуйтесь, это не так, и ваши данные на данный момент могут быть все еще нетронутыми. Итак, с учетом сказанного, вот различные методы исправления невозможности монтировать хранилище в TWRP Recovery.
Как исправить невозможность смонтировать хранилище в TWRP Recovery
Мы поделимся тремя разными способами решения этой проблемы. Следуйте инструкциям в том же порядке, как указано. Просто убедитесь, что ваше устройство уже загружено в TWRP. Е
Исправление 1: удалить экран блокировки
Если вы используете графический ключ на своем устройстве, TWRP не сможет его расшифровать. Рекомендуется переключиться на пин-код или пароль.
- Для этого, если вы загружены в TWRP, перезагрузите устройство в Системе.
- После загрузки перейдите в Настройки > Безопасность и экран блокировки > Блокировка экрана.
- Выберите из списка PIN-код или пароль. Теперь перезагрузите устройство обратно в TWRP.
- Теперь программа восстановления попросит вас ввести PIN-код / пароль. Введите его, и ваше хранилище будет зашифровано.
Теперь попробуйте прошить нужные файлы и посмотрите, исправлена ли проблема с невозможностью монтировать хранилище в TWRP Recovery.
Исправление 2: восстановить или изменить файловую систему
Вы также можете попробовать восстановить или изменить файловую систему вашего устройства. Все это можно было сделать прямо из самого TWRP.
- Итак, загрузите ваше устройство в TWRP Recovery.
- Затем перейдите в Wipe > Advanced Wipe, нажмите Wipe и нажмите Advanced Wipe.
- Теперь выберите раздел данных и нажмите на опцию «Восстановить» или «Изменить файловую систему». Затем нажмите «Восстановить файловую систему» и дождитесь завершения процесса. Проверьте, может ли он исправить проблему с монтированием.
- Если он все еще там, то снова зайдите в «Восстановить или изменить файловую систему» и на этот раз нажмите «Изменить файловую систему».
- В появившемся меню выберите EXT 2 и проведите пальцем вправо для подтверждения.
- После этого вернитесь к EXT 4 и проведите пальцем вправо, чтобы подтвердить это.
- Теперь перейдите в главное меню TWRP и перейдите к опции Mount
- Выберите раздел Data и попробуйте прошить нужные файлы.
Убедитесь, что вы по-прежнему получаете сообщение об ошибке «Невозможно смонтировать хранилище при восстановлении TWRP».
Исправление 3: форматирование внутренней памяти
Если ни один из вышеперечисленных методов не помог устранить проблему с монтированием, возможно, вам придется выбрать ядерный вариант. Форматирование внутреннего хранилища кажется единственным выходом. Это, в свою очередь, сотрет все данные, имеющиеся на вашем устройстве.
Убедитесь, что вы создали эту резервную копию на SD-карте или USB OTG, а не в памяти телефона, так как мы собираемся полностью стереть этот раздел. Когда вы закончите резервное копирование, выполните следующие действия.
- Загрузите устройство в TWRP Recovery.
- Перейдите в Wipe > Advanced Wipe и выберите Internal Storage.
- Наконец, проведите пальцем вправо, чтобы отформатировать этот раздел (все данные будут стерты).
- Как только это будет сделано, ошибка монтирования будет исправлена. Имейте в виду, что внутреннее хранилище может по-прежнему отображаться как 0 МБ. Но на этот раз это данные в реальном времени (ваше внутреннее хранилище очищается, следовательно, используется 0 МБ пространства).
Мы поделились тремя разными методами для одного и того же, дайте нам знать, какой из них сработал за вас.
A couple of things to check out. I do something similar and you can test mount it directly using the mount command to make sure you have things setup right.
Permissions on credentials file
Make sure that this file is permissioned right.
$ sudo ls -l /etc/smb_credentials.txt
-rw-------. 1 root root 54 Mar 24 13:19 /etc/smb_credentials.txt
Verbose mount
You can coax more info out of mount using the -v switch which will often times show you where things are getting tripped up.
$ sudo mount -v -t cifs //server/share /mnt
-o credentials=/etc/smb_credentials.txt
Resulting in this output if it works:
mount.cifs kernel mount options: ip=192.168.1.14,unc=servershare,credentials=/etc/smb_credentials.txt,ver=1,user=someuser,domain=somedom,pass=********
Check the logs
After running the above mount command take a look inside your dmesg and /var/log/messages or /var/log/syslog files for any error messages that may have been generated when you attempted the mount.
Type of security
You can pass a lot of extra options via the -o .. switch to mount. These options are technology specific, so in your case they’re applicable to mount.cifs specifically. Take a look at the mount.cifs man page for more on all the options you can pass.
I would suspect you’re missing an option to sec=.... Specifically one of these options:
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.
You may need to adjust the sec=... option so that it’s either sec=ntlm or sec=ntlmssp.
References
- Thread: mount -t cifs results gives mount error(13): Permission denied
A couple of things to check out. I do something similar and you can test mount it directly using the mount command to make sure you have things setup right.
Permissions on credentials file
Make sure that this file is permissioned right.
$ sudo ls -l /etc/smb_credentials.txt
-rw-------. 1 root root 54 Mar 24 13:19 /etc/smb_credentials.txt
Verbose mount
You can coax more info out of mount using the -v switch which will often times show you where things are getting tripped up.
$ sudo mount -v -t cifs //server/share /mnt
-o credentials=/etc/smb_credentials.txt
Resulting in this output if it works:
mount.cifs kernel mount options: ip=192.168.1.14,unc=servershare,credentials=/etc/smb_credentials.txt,ver=1,user=someuser,domain=somedom,pass=********
Check the logs
After running the above mount command take a look inside your dmesg and /var/log/messages or /var/log/syslog files for any error messages that may have been generated when you attempted the mount.
Type of security
You can pass a lot of extra options via the -o .. switch to mount. These options are technology specific, so in your case they’re applicable to mount.cifs specifically. Take a look at the mount.cifs man page for more on all the options you can pass.
I would suspect you’re missing an option to sec=.... Specifically one of these options:
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.
You may need to adjust the sec=... option so that it’s either sec=ntlm or sec=ntlmssp.
References
- Thread: mount -t cifs results gives mount error(13): Permission denied
- Печать
Страницы: [1] 2 Все Вниз
Тема: проблемы с монтированием (Прочитано 2169 раз)
0 Пользователей и 1 Гость просматривают эту тему.
redway
при монтировании флешек и дисков (кроме тех что прописаны в fstab) — нет прав на запись (Permission denied)
sudo mount /dev/sdc1 /mnt/sdc1
mount
...
/dev/sda2 on /mnt/sda2 type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096)
securityfs on /sys/kernel/security type securityfs (rw)
/dev/sdc1 on /mnt/disk type vfat (rw)
После монтирования на папку /mnt/sdc1 выставляются права drwxr-xr-x и дата создания папки 1970-01-01 03:00
ls -l /mnt/
drwxrwxrwx 2 root root 4096 2009-08-10 20:55 SD
drwxrwxrwx 1 root root 45056 2009-08-10 11:56 sda2
drwxr-xr-x 2 root root 4096 1970-01-01 03:00 sdc1
подскажите куда копать,
uname -a
Linux ubuntu 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux
dmesq | tail
[ 513.861906] sd 6:0:0:0: [sdc] Write Protect is off
[ 513.861911] sd 6:0:0:0: [sdc] Mode Sense: 03 00 00 00
[ 513.861916] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[ 513.866783] sd 6:0:0:0: [sdc] 15660032 512-byte hardware sectors: (8.01 GB/7.46 GiB)
[ 513.869907] sd 6:0:0:0: [sdc] Write Protect is off
[ 513.869912] sd 6:0:0:0: [sdc] Mode Sense: 03 00 00 00
[ 513.869916] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[ 513.870568] sdc: sdc1
[ 513.871502] sd 6:0:0:0: [sdc] Attached SCSI removable disk
[ 513.871618] sd 6:0:0:0: Attached scsi generic sg3 type 0
lsusb
Bus 001 Device 005: ID 058f:6366 Alcor Micro Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 1267:0201 Logic3 / SpectraVideo plc A4Tech SWOP-3 Mouse
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
toshcka
наверное, перед монтированием стоит задать права на директорию?
ArcFi
sudo chown -R $USER:$USER /mount/point
redway
наверное, перед монтированием стоит задать права на директорию?
до монтирования
drwxrwxrwx 2 root root 4096 2009-08-10 20:55 SD
drwxrwxrwx 1 root root 45056 2009-08-10 11:56 sda2
drwxrwxrwx 2 root root 4096 2009-08-10 21:55 sdc1
после
drwxrwxrwx 2 root root 4096 2009-08-10 20:55 SD
drwxrwxrwx 1 root root 45056 2009-08-10 11:56 sda2
drwxr-xr-x 2 root root 4096 1970-01-01 03:00 sdc1
2 ArcFi
root@ubuntu:/home/alex# chown -R alex:alex /mnt/sdc1
chown: changing ownership of `/mnt/sdc1': Operation not permitted
« Последнее редактирование: 10 Августа 2009, 23:02:23 от redway »
фирэфохэ
root@ubuntu:/home/alex# chown -R alex:alex /mnt/sdc1ну пишет тебе — нехватает прав
chown: changing ownership of `/mnt/sdc1': Operation not permitted
=> добавь sudo
http://i18.ЗАПРЕЩЁННЫЙ РЕСУРС/big/2011/0325/6d/19eaa72dd24048a6fb0587832c4b096d.gif КДЕ — УГ. Дебиан — недоось.
redway
root@ubuntu:/home/alex# chown -R alex:alex /mnt/sdc1ну пишет тебе — нехватает прав
chown: changing ownership of `/mnt/sdc1': Operation not permitted
=> добавь sudo
я под root’ом
Pingvinator
Этим летом мне попались 2 флешки с такой же проблеммой: но с ними было по серьезному. На флешке был создан загрузочный раздел и в нем сидел autorun.ini Сначала я думал что это легко удаляется, тем более что из-под линукса очень часто приходится чистить флешки пользователей. Но не тут-то было: выдает ошибку о том что диск только для чтения. Еще один интересный нюанс: флешка на 1Gb а в свойствах показывает что там 8Gb !!! Короче пришлось форматировать ее на низком уровне утилитой от производителя. Не факт но может быть и похожая ситуация, а еще на всякий случай зайди в СИСТЕМА—АДМИНИСТРИРОВАНИЕ—ПОЛЬЗОВАТЕЛИ И ГРУППЫ—ПРИВЕЛЕГИИ и посмотри есть ли у твоего пользователя разрешение на монтирование внешних накопителей. И вообще там много станет понятно по правам доступа.
root@ubuntu:/home/alex# chown -R alex:alex /mnt/sdc1ну пишет тебе — нехватает прав
chown: changing ownership of `/mnt/sdc1': Operation not permitted
=> добавь sudoЗачем sudo если он и так уже под root-консолью? Решетка уже и так есть … А ругается он на то что операция не может быть выполнена, невыполнима, не под-держивается. При нехватке прав — Access denied
… чудна и загадочна эта Ось: ось Microsoft Windows …
фирэфохэ
Извиняюсь не заметил.
Кстати у меня все происходит точно так же.
При монтировании добавь
-o uid=1000,gid=1000
и man mount почитай насчет опций для фата (кодировка там и все такое)
« Последнее редактирование: 11 Августа 2009, 00:05:56 от persona_non_grata »
http://i18.ЗАПРЕЩЁННЫЙ РЕСУРС/big/2011/0325/6d/19eaa72dd24048a6fb0587832c4b096d.gif КДЕ — УГ. Дебиан — недоось.
Pingvinator
бывает, усе мы человеки …
… чудна и загадочна эта Ось: ось Microsoft Windows …
redway
2 Pingvinator
проблема (появилась пару дней назад) не только с флешками (3 штуки), но и дисками (fat,ext3), а с дисками ntfs все ок.
привилегии
« Последнее редактирование: 11 Августа 2009, 00:16:53 от redway »
фирэфохэ
Так если при монтировании добавь
-o uid=1000,gid=1000 работает?
http://i18.ЗАПРЕЩЁННЫЙ РЕСУРС/big/2011/0325/6d/19eaa72dd24048a6fb0587832c4b096d.gif КДЕ — УГ. Дебиан — недоось.
Pingvinator
Или я уже тупить начал, либо ты ошибся при написании: че то я не понял вот это:
sudo mount /dev/sdc1 /mnt/sdc1
mount
Код:
…
/dev/sda2 on /mnt/sda2 type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096)
securityfs on /sys/kernel/security type securityfs (rw)
/dev/sdc1 on /mnt/disk type vfat (rw)
Ты вроде монтируешь в директорию /mnt/sdc1 а команда моунт показывает что у тебя примонтирован /dev/sdc1 в /mnt/disk
Я правильно понял? И по правилам вообще-то надо указывать тип ФС при монтировании (примеры подробно описаны в man mount)
И еще вопрос, может я че пропустил: зачем монтировать флешку в директорию самому? Она должна монтироваться в /media причем сама …
… чудна и загадочна эта Ось: ось Microsoft Windows …
redway
Или я уже тупить начал, либо ты ошибся при написании: че то я не понял вот это:
sudo mount /dev/sdc1 /mnt/sdc1
mount
Код:
…
/dev/sda2 on /mnt/sda2 type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096)
securityfs on /sys/kernel/security type securityfs (rw)
/dev/sdc1 on /mnt/disk type vfat (rw)
Ты вроде монтируешь в директорию /mnt/sdc1 а команда моунт показывает что у тебя примонтирован /dev/sdc1 в /mnt/disk
Я правильно понял?
мой косяк — сначала в /mnt/disk монтировал, потом удалил (на всякий случай) и создал /mnt/sdc1
И еще вопрос, может я че пропустил: зачем монтировать флешку в директорию самому? Она должна монтироваться в /media причем сама …
на ubuntu+openbox перехожу
Так если при монтировании добавь
-o uid=1000,gid=1000 работает?
спасибо помогло
Хотелось-бы конечно узнать что произошло, а то каждый раз опци добавлять лень.
Благодарю всех за помощь.
« Последнее редактирование: 11 Августа 2009, 01:25:53 от redway »
фирэфохэ
А автоматом флэшки не монтируются? в /media/disk или типа того
http://i18.ЗАПРЕЩЁННЫЙ РЕСУРС/big/2011/0325/6d/19eaa72dd24048a6fb0587832c4b096d.gif КДЕ — УГ. Дебиан — недоось.
pipe
- Печать
Страницы: [1] 2 Все Вверх
Несколько вещей, чтобы проверить. Я делаю нечто подобное, и вы можете протестировать монтирование напрямую, используя 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=servershare,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.
Ссылки
- Тема: mount -t cifs приводит к ошибке монтирования (13): разрешение запрещено
- Печать
Страницы: [1] 2 Все Вниз
Тема: проблемы с монтированием (Прочитано 2246 раз)
0 Пользователей и 1 Гость просматривают эту тему.
redway
при монтировании флешек и дисков (кроме тех что прописаны в fstab) — нет прав на запись (Permission denied)
sudo mount /dev/sdc1 /mnt/sdc1
mount
...
/dev/sda2 on /mnt/sda2 type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096)
securityfs on /sys/kernel/security type securityfs (rw)
/dev/sdc1 on /mnt/disk type vfat (rw)
После монтирования на папку /mnt/sdc1 выставляются права drwxr-xr-x и дата создания папки 1970-01-01 03:00
ls -l /mnt/
drwxrwxrwx 2 root root 4096 2009-08-10 20:55 SD
drwxrwxrwx 1 root root 45056 2009-08-10 11:56 sda2
drwxr-xr-x 2 root root 4096 1970-01-01 03:00 sdc1
подскажите куда копать,
uname -a
Linux ubuntu 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux
dmesq | tail
[ 513.861906] sd 6:0:0:0: [sdc] Write Protect is off
[ 513.861911] sd 6:0:0:0: [sdc] Mode Sense: 03 00 00 00
[ 513.861916] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[ 513.866783] sd 6:0:0:0: [sdc] 15660032 512-byte hardware sectors: (8.01 GB/7.46 GiB)
[ 513.869907] sd 6:0:0:0: [sdc] Write Protect is off
[ 513.869912] sd 6:0:0:0: [sdc] Mode Sense: 03 00 00 00
[ 513.869916] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[ 513.870568] sdc: sdc1
[ 513.871502] sd 6:0:0:0: [sdc] Attached SCSI removable disk
[ 513.871618] sd 6:0:0:0: Attached scsi generic sg3 type 0
lsusb
Bus 001 Device 005: ID 058f:6366 Alcor Micro Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 1267:0201 Logic3 / SpectraVideo plc A4Tech SWOP-3 Mouse
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
toshcka
наверное, перед монтированием стоит задать права на директорию?
ArcFi
sudo chown -R $USER:$USER /mount/point
redway
наверное, перед монтированием стоит задать права на директорию?
до монтирования
drwxrwxrwx 2 root root 4096 2009-08-10 20:55 SD
drwxrwxrwx 1 root root 45056 2009-08-10 11:56 sda2
drwxrwxrwx 2 root root 4096 2009-08-10 21:55 sdc1
после
drwxrwxrwx 2 root root 4096 2009-08-10 20:55 SD
drwxrwxrwx 1 root root 45056 2009-08-10 11:56 sda2
drwxr-xr-x 2 root root 4096 1970-01-01 03:00 sdc1
2 ArcFi
root@ubuntu:/home/alex# chown -R alex:alex /mnt/sdc1
chown: changing ownership of `/mnt/sdc1': Operation not permitted
« Последнее редактирование: 10 Августа 2009, 23:02:23 от redway »
фирэфохэ
root@ubuntu:/home/alex# chown -R alex:alex /mnt/sdc1ну пишет тебе — нехватает прав
chown: changing ownership of `/mnt/sdc1': Operation not permitted
=> добавь sudo
http://i18.ЗАПРЕЩЁННЫЙ РЕСУРС/big/2011/0325/6d/19eaa72dd24048a6fb0587832c4b096d.gif КДЕ — УГ. Дебиан — недоось.
redway
root@ubuntu:/home/alex# chown -R alex:alex /mnt/sdc1ну пишет тебе — нехватает прав
chown: changing ownership of `/mnt/sdc1': Operation not permitted
=> добавь sudo
я под root’ом
Pingvinator
Этим летом мне попались 2 флешки с такой же проблеммой: но с ними было по серьезному. На флешке был создан загрузочный раздел и в нем сидел autorun.ini Сначала я думал что это легко удаляется, тем более что из-под линукса очень часто приходится чистить флешки пользователей. Но не тут-то было: выдает ошибку о том что диск только для чтения. Еще один интересный нюанс: флешка на 1Gb а в свойствах показывает что там 8Gb !!! Короче пришлось форматировать ее на низком уровне утилитой от производителя. Не факт но может быть и похожая ситуация, а еще на всякий случай зайди в СИСТЕМА—АДМИНИСТРИРОВАНИЕ—ПОЛЬЗОВАТЕЛИ И ГРУППЫ—ПРИВЕЛЕГИИ и посмотри есть ли у твоего пользователя разрешение на монтирование внешних накопителей. И вообще там много станет понятно по правам доступа.
root@ubuntu:/home/alex# chown -R alex:alex /mnt/sdc1ну пишет тебе — нехватает прав
chown: changing ownership of `/mnt/sdc1': Operation not permitted
=> добавь sudoЗачем sudo если он и так уже под root-консолью? Решетка уже и так есть … А ругается он на то что операция не может быть выполнена, невыполнима, не под-держивается. При нехватке прав — Access denied
… чудна и загадочна эта Ось: ось Microsoft Windows …
фирэфохэ
Извиняюсь не заметил.
Кстати у меня все происходит точно так же.
При монтировании добавь
-o uid=1000,gid=1000
и man mount почитай насчет опций для фата (кодировка там и все такое)
« Последнее редактирование: 11 Августа 2009, 00:05:56 от persona_non_grata »
http://i18.ЗАПРЕЩЁННЫЙ РЕСУРС/big/2011/0325/6d/19eaa72dd24048a6fb0587832c4b096d.gif КДЕ — УГ. Дебиан — недоось.
Pingvinator
бывает, усе мы человеки …
… чудна и загадочна эта Ось: ось Microsoft Windows …
redway
2 Pingvinator
проблема (появилась пару дней назад) не только с флешками (3 штуки), но и дисками (fat,ext3), а с дисками ntfs все ок.
привилегии
« Последнее редактирование: 11 Августа 2009, 00:16:53 от redway »
фирэфохэ
Так если при монтировании добавь
-o uid=1000,gid=1000 работает?
http://i18.ЗАПРЕЩЁННЫЙ РЕСУРС/big/2011/0325/6d/19eaa72dd24048a6fb0587832c4b096d.gif КДЕ — УГ. Дебиан — недоось.
Pingvinator
Или я уже тупить начал, либо ты ошибся при написании: че то я не понял вот это:
sudo mount /dev/sdc1 /mnt/sdc1
mount
Код:
…
/dev/sda2 on /mnt/sda2 type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096)
securityfs on /sys/kernel/security type securityfs (rw)
/dev/sdc1 on /mnt/disk type vfat (rw)
Ты вроде монтируешь в директорию /mnt/sdc1 а команда моунт показывает что у тебя примонтирован /dev/sdc1 в /mnt/disk
Я правильно понял? И по правилам вообще-то надо указывать тип ФС при монтировании (примеры подробно описаны в man mount)
И еще вопрос, может я че пропустил: зачем монтировать флешку в директорию самому? Она должна монтироваться в /media причем сама …
… чудна и загадочна эта Ось: ось Microsoft Windows …
redway
Или я уже тупить начал, либо ты ошибся при написании: че то я не понял вот это:
sudo mount /dev/sdc1 /mnt/sdc1
mount
Код:
…
/dev/sda2 on /mnt/sda2 type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096)
securityfs on /sys/kernel/security type securityfs (rw)
/dev/sdc1 on /mnt/disk type vfat (rw)
Ты вроде монтируешь в директорию /mnt/sdc1 а команда моунт показывает что у тебя примонтирован /dev/sdc1 в /mnt/disk
Я правильно понял?
мой косяк — сначала в /mnt/disk монтировал, потом удалил (на всякий случай) и создал /mnt/sdc1
И еще вопрос, может я че пропустил: зачем монтировать флешку в директорию самому? Она должна монтироваться в /media причем сама …
на ubuntu+openbox перехожу
Так если при монтировании добавь
-o uid=1000,gid=1000 работает?
спасибо помогло
Хотелось-бы конечно узнать что произошло, а то каждый раз опци добавлять лень.
Благодарю всех за помощь.
« Последнее редактирование: 11 Августа 2009, 01:25:53 от redway »
фирэфохэ
А автоматом флэшки не монтируются? в /media/disk или типа того
http://i18.ЗАПРЕЩЁННЫЙ РЕСУРС/big/2011/0325/6d/19eaa72dd24048a6fb0587832c4b096d.gif КДЕ — УГ. Дебиан — недоось.
pipe
- Печать
Страницы: [1] 2 Все Вверх
A couple of things to check out. I do something similar and you can test mount it directly using the mount command to make sure you have things setup right.
Permissions on credentials file
Make sure that this file is permissioned right.
$ sudo ls -l /etc/smb_credentials.txt
-rw-------. 1 root root 54 Mar 24 13:19 /etc/smb_credentials.txt
Verbose mount
You can coax more info out of mount using the -v switch which will often times show you where things are getting tripped up.
$ sudo mount -v -t cifs //server/share /mnt
-o credentials=/etc/smb_credentials.txt
Resulting in this output if it works:
mount.cifs kernel mount options: ip=192.168.1.14,unc=servershare,credentials=/etc/smb_credentials.txt,ver=1,user=someuser,domain=somedom,pass=********
Check the logs
After running the above mount command take a look inside your dmesg and /var/log/messages or /var/log/syslog files for any error messages that may have been generated when you attempted the mount.
Type of security
You can pass a lot of extra options via the -o .. switch to mount. These options are technology specific, so in your case they’re applicable to mount.cifs specifically. Take a look at the mount.cifs man page for more on all the options you can pass.
I would suspect you’re missing an option to sec=.... Specifically one of these options:
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.
You may need to adjust the sec=... option so that it’s either sec=ntlm or sec=ntlmssp.
References
- Thread: mount -t cifs results gives mount error(13): Permission denied
I know this question has been asked before, but I’ve been looking for a solution for a couple of hours now and nothing seems to be working.
The frustrating thing is that it used to work on my previous install, so I know the commands I try should work.
I’m running a vanilla install of Ubuntu 13.04 server.
I have a server running at 192.168.1.130 and two shares: LaCie and Seagate 2TB.
I used to have these lines in my fstab file:
//192.168.1.130/Seagate402TB /home/Windows cifs user=admin,password=password,uid=1000 0 0
Now that I re-installed my server, but don’t need it permanently I tried the following:
sudo mount.cifs //192.168.1.130/LaCie ~/lacie -o user=admin
or
sudo mount -t cifs -o username='admin',password='<password>' //192.168.1.130/LaCie ~/lacie
However, I get the error mount error(13): Permission denied.
I’m sure the credentials are correct. Nothing has changed at the windows side.
Also, I installed the packages samba, cifs-utils too. Nothing helped.
There are a couple of ways how to mount a CIFS/Samba share on a Linux client. However some tutorials are outdated and meanwhile completely wrong. I just ran into a (stupid) case of a wrong mount.cifs syntax:
root@focal:~# mount -t cifs //server/Share /mnt -o rw,user=domainmyuser,password=secret
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
Unfortunately, the additional output in dmesg is not helpful to figure out the problem:
root@focal:~# dmesg
[…]
[16444886.307684] CIFS: Attempting to mount //server/Share
[16444886.307717] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
[16444886.539770] Status code returned 0xc000006d STATUS_LOGON_FAILURE
[16444886.539795] CIFS VFS: server Send error in SessSetup = -13
[16444886.539901] CIFS VFS: cifs_mount failed w/return code = -13
After additional try and errors (and looking up a recent share mount from the history), the problem turned out to be the user=domainmyuser syntax. This way of combining the domain/workgroup and the username is not working (anymore).
Note: Both user= and username= are accepted in the options.
Instead use:
root@focal:~# mount -t cifs «//server/Share» /mnt -o «user=myuser,password=secret,workgroup=DOMAIN»
root@focal:~# ll /mnt/
total 0
drwxr-xr-x 2 root root 0 Sep 1 2020 _Archiv
drwxr-xr-x 2 root root 0 Aug 9 12:10 Client
[..]
This way it worked.
Of course the password should not be used on the command line, so for the final (and automatic) mount of the share use the following entry in /etc/fstab:
root@focal:~# cat /etc/fstab
[…]
# Mount CIFS share from server
//server/Share /mnt cifs rw,relatime,vers=3.1.1,credentials=/etc/samba/servershare.conf,uid=0 0 0
Where /etc/samba/servershare.conf contains the credentials:
root@focal:~# cat /etc/samba/servershare.conf
user=myuser
password=secret
domain=DOMAIN
Add a comment
Show form to leave a comment
Comments (newest first)
Ed from wrote on Jan 27th, 2023:
In my case (mounting win 2019 share in RHEL9) when using double apostrophe: «user=myuser…» was outputing:
«bash: !,workgroup=$MY_DOMAIN: event not found»
Switching to single apostrophe ‘user=mysers…’ did the trick
ck from Switzerland wrote on Nov 29th, 2022:
Keith, make sure you have the cifs-utils and smbclient packages installed on your Ubuntu. Still an error? Try to connect to the share using the smbclient command. It could also be a SMB protocol mismatch. Check out this article, describing Samba protocol configuration on the client.
Keith from United States wrote on Nov 29th, 2022:
I’ve tried for the past 3 hours, 5AM in the morning now, and I’ve tried everything from every other website and this one and still get the exact same errors. Tried it with just sudo, then root. Same thing. Host OS is ubuntu server trying to mount a network share from my Synology NAS.
AJav from wrote on Sep 19th, 2022:
very good, Thanks !
simonpunk2016 from wrote on Aug 1st, 2022:
Thank you sir, never know the mount option has changed, because I just successfully mounted the cifs last month, thought my Manjaro has come to an end.
simonpunk2016 from wrote on Jul 29th, 2022:
Thank you sir, never know the mount option has changed, because I just successfully mounted the cifs last month, thought my Manjaro has come to an end.
Jesko from wrote on Feb 10th, 2022:
I had exact the same error, but different reason. On a freshly installed (old) Ubuntu 16.04 LTS (last 32Bit version). My reason was: There was no cifs-utils installed! so «sudo apt install cifs-utils» was the solution. I just write here because I crawled through hundreds of comments.
If you recently updated your RedHat or CentOS 7.6 system, you may suddenly start getting “Permission Denied” errors when attempting to mount SMB shares via CIFS. Typical error messages in syslog look like this:
kernel: Status code returned 0xc000006d STATUS_LOGON_FAILURE kernel: CIFS VFS: Send error in SessSetup = -13 kernel: CIFS VFS: cifs_mount failed w/return code = -13
Configuration that triggered the problem
- Synology NAS with latest operating system shares a volume via SMB
- CentOS 7 Linux server mounts SMB share using a local username and password (NOT domain credentials)
- cifs-utils version 6.2 installed in May of 2019 (this by itself worked fine)
- libsmbclient just updated to 4.9.1-6
- libmount just updated to 2.23.2-61
- CIFS mount options: vers=3.0,credentials=/root/credentials.txt,sec=ntlmsspi
- File /root/credentials.txt contained a username and password that are LOCAL to the SMB server
Troubleshooting & solution
I was able to isolate the problem to mount.cifs with the following procedure:
- Mount the SMB share from a Windows host, using the same credentials as the Linux host. This proved that the credentials were valid and there were no problems on the SMB server side.
- Access the SMB share from the Linux host using smbclient. This step ruled out any network issues between the Linux and SMB server, and verified that the version of Samba installed on the Linux host was compatible with the SMB server.
I found the solution in a post from a couple of years ago in the askubuntu forum on StackExchange. It seems that one of the recent CentOS/RedHat updates changed some default behavior in the way that mount.cifs authenticates to SMB shares. When authenticating as a local user, you now have to specify the host as the domain. I did this by adding one line to the credentials file that is referenced from /etc/fstab as shown below:
//172.1.1.1/share_name /mnt/mountpoint cifs vers=3.0,credentials=/root/credentials.txt,sec=ntlmsspi
Here are the contents of file /root/credentials.txt:
username=my_username
password=my_password
domain=172.1.1.1I am not sure why this problem showed up now; it seems like it should have occurred months ago when we updated to latest version of cifs-utils. I’m also unsure if this problem will occur if you’re attempting to authenticate as a domain user. Let me know in the comments!
- Печать
Страницы: [1] 2 Все Вниз
Тема: Уважаемые знатоки, помогите замонтить ресурс Windows Server 2003 на Ubuntu 13,04 (Прочитано 10290 раз)
0 Пользователей и 1 Гость просматривают эту тему.
Antiseptik
Есть сервер Windows Server 2003. На нём есть расшаренный сетевой ресурс. Мне нужно смонтировать этот сетевой ресурс на ПК с linux Ubutu 13.04, что, собственно говоря, у меня и не получается.
Допустим: IP сервака-192.168.0.1, расшаренный сетевой ресурс на нём (сетевая папка)-1Cbase
Путь, куда монтирую на Ubutu — /home/buhg/Base1C
Монтирую так (пока только через терминал — для проверки):
sudo mount -t cifs //192.168.0.1/1Cbase /home/buhg/Base1C -o username=buhg/WORKGROUP%123456,iocharset=utf8,rw,file_mode=0777,dir_mode=0777
и так:
sudo mount -t cifs //192.168.0.1/1Cbase /home/buhg/Base1C -o username=buhg,password=123456,iocharset=utf8,rw,file_mode=0777,dir_mode=0777
и даже через mount.gifs пробовал и другие разные комбинации. Никакие танцы с бубнами не помогают=(.
Если просто набрать, чтобы потом попросил паролики:
sudo mount -t cifs //192.168.0.1/1Cbase /home/buhg/Base1C -o username=buhg
Потом попросит паролик. Ввожу. И вижу тоже самое, что и с предыдущими способами:
mount error(13): Permission denied
Refer to the mount.cifs( 8)manual page (e.g. man mount.cifs)
Что самое интересное, если монтировать сетевой ресурс с win XP подобными командами, то всё замечательно монтируется.
Уже вертел права пользователя, службы, политики безопасности и вкривь, и вкось на серваке-ничего не получается. Никаких доменов на серваке не установлено. Простая сетка и всё. Перепробовал уйму способов, что нашёл и инете — результат отрицательный, поэтому и обращаюсь к Вам за помощью.
« Последнее редактирование: 07 Ноября 2013, 11:20:58 от Antiseptik »
oermolaev
Antiseptik
Да я уже там был, вообщем перепробовал всё, что описано относительно терминала, но ничего так и не помогло. Если у меня в терминале получится, то и через fstab я по-идее смонтирую, наверное. Или я ошибаюсь? Хотя, мне бы хотя-бы так для начала.
Я что-то не так делаю, а что — понять не могу. Неделю бьюсь с этим вопросом.
Давайте поподробней.
На сервере под управлением Windows Server 2003. Его IP: 192.168.0.1. Рабочая группа: WORKGROUP. На серваке есть встроенная учётная запись: «администратор». Добавил туда дополнительную учётку Buhg в «локальные пользователи и группыПользователи«. Включил данную учётку на всякий случай в группу «администраторы«.
Расшарил папку на серваке 1Cbase. На неё дал следующие права доступа: Доступ на измнение т.е. чтение и запись дал ВСЕМ и пользователю buhg отдельно на тоже самое.
Есть ПК под управлением linux Ubuntu 13.04, на который будем монтировать. Пользователь: buhg. Рабочая группа: WORKGROUP
Дальше (в первом случае) запускаю терминал и ввожу следующее:
sudo mount -t cifs //192.168.0.1/1Cbase /home/buhg/Base1C -o username=buhg,password=123456,iocharset=utf8,rw,file_mode=0777,dir_mode=0777
где:
//192.168.0.1/1Cbase — шара на сервере
/home/buhg/Base1C — куда монтирую
cifs — Common Internet File System
rw — чтение запись
user=buhg,password=123456 — пользователь, пароль.
iocharset=utf8 — кодировка
file_mode=0777,dir_mode=0777 — права доступа
————
Вся трабла в том, что если брать в качестве сервака Windows XP, то всё монтируется. А вот под Windows Server 2003 — нет.
Может мне что-то дописать надо?
« Последнее редактирование: 07 Ноября 2013, 15:03:22 от Antiseptik »
oermolaev
Может мне что-то дописать надо?
Может наоборот, убрать всё лишнее и добиться результата, а потом уже добавлять разные примочки?
Сейчас у себя монтирую раздел на win2003:
# mount -t cifs //192.168.0.21/D$ /mnt/test -o username=admin
Всё ОК!
А ошибка
mount error(13): Permission denied
Refer to the mount.cifs( 8)manual page (e.g. man mount.cifs)
возникает когда ввожу заведомо не правильный пароль.
Antiseptik
Спасибо большое, что Вы мне помогаете.
Да, действительно, ошибка возникает на пароле, но вот почему, пока не ясно.
По Вашему примеру учётка «admin» — это учётка, созданная в «локальные пользователипользователи» на сервере и она не является встроенной учётной записью? Я правильно понял? Ей соответствует определённый пароль допустим.
Если да, то у меня тоже на сервре создана учётка buhg и ей соответствует допустим пароль 123456, который я задал.
Набираю в терминале:
sudo mount -t cifs //192.168.0.1/1Cbase /home/buh1/Base1C -o username=buhg
он запрашивает 1 раз
password:
набираю: 123456
и снова та же ошибка.
Пользователь решил продолжить мысль 07 Ноября 2013, 16:17:11:
может у меня трабла в расшаренном сетевом ресурсе?
« Последнее редактирование: 07 Ноября 2013, 16:18:19 от Antiseptik »
oermolaev
Antiseptik,
может… Ну попробуйте смонтировать через административный ресурс. что то типа: //192.168.0.1/c$/1Cbase
хотя у меня и шара монтируется от обычного пользователя:
mount -t cifs //192.168.0.21/Bases /mnt/test -o username=oermolaev
так что у вас скорее всего проблема со стороны windows, типа «Общий доступ и безопасность» надо посмотреть.
« Последнее редактирование: 07 Ноября 2013, 16:45:18 от oermolaev »
Antiseptik
создал на серваке папку 1с. Дал доступ. Права и разрешения не раздавал. Ощий ресурс определён как 1с$.
Набираю в терминале:
sudo mount -t cifs //192.168.0.1/1c$ /home/buhg/Base1C -o username=buhg
Так?
попросил пароль 2 раза. в обоих случаях ввёл 123456
та же ошибка. Что-то не соображаю уже
Пользователь решил продолжить мысль 07 Ноября 2013, 17:19:39:
1й раз спросил собственно пароль на машине с Ubuntu
2й раз спросил пароль на учётке buhh на серваке
попробовал через самбу зайти, через графический интерфейс. выдало окно ауинтификации. логин: Buhg, Раб. группа: WORKGROUP, пароль набрал: 123456. зашёл нормально.
« Последнее редактирование: 07 Ноября 2013, 17:19:39 от Antiseptik »
oermolaev
Antiseptik,
может пароль у вас там какой хитрый — попробуйте через файл credentials= авторизовываться
Пользователь решил продолжить мысль 07 Ноября 2013, 17:23:56:
1й раз спросил собственно пароль на машине с Ubuntu
2й раз спросил пароль на учётке buhh на серваке
а вот в этом я уже не уверен. Что то у меня тоже спросили два раза пароль, однако, оба раза это был вопрос от сервера..
про повторном монтировании уже спрашивает один раз… 
« Последнее редактирование: 07 Ноября 2013, 17:26:51 от oermolaev »
Antiseptik
Мне право, очень не удобно Вас просить, но не могли бы Вы сверить мои пиолитики безопасности со ссвоими, если у вас тоже winserver 2003.
вот мои.
Ну или скиньте мне свою пожалуйста на мыло Antiseptik@mail.ru
Пользователь решил продолжить мысль 08 Ноября 2013, 12:17:14:
Попробую перебить систему с «нуля», без добавления ролей сервера. Может быть поможет=))
« Последнее редактирование: 08 Ноября 2013, 12:17:14 от Antiseptik »
oermolaev
Antiseptik,
«перебить» — новое для меня слово 
Вы хотите сервер 2003 заново поднять? Может в VirtualBox попробовать сперва?
Antiseptik
Здравствуйте, спасибо за инфу о политиках безопасности.
О виртульной машине как-то не додумался. Систему установил заново, но параметры «локальной политики безопасности» не такие, как у Вас. У меня очень мало параметров установлено как «не определно», остальные «вкл/откл». Привести их к такому виду, как у Вас не получается. Или «вкл», или «откл».
В «локальных пользователях» создал пользователя buhg с паролем buhg. Дал доступ на папку 1с. В разрешениях на папку дал доступ ВСЕМ на чтение и запись.
Набираю команду в терминале:
sudo mount -t cifs //192.168.0.1/1c /home/buhg/Base1C -o username=buhg
спрашивает пароль 1й раз.
набираю пароль 1 й раз с ПК на Ubuntu: buhg
спрашивает пароль 2й раз.
набираю пароль 2й раз локального польщователя на сервере: buhg
курсор игает продолжительное время.
после выдаётся ошибка, но уже другая: mount error(115): Operation now in progress
Сейчас ищу на просторах интернет, что это за ошибка и что сней делать
Пользователь решил продолжить мысль 08 Ноября 2013, 14:24:30:
отключил брандмауэр на сервере.
sudo mount -t cifs //192.168.0.1/1c /home/buhg/Base1C -o username=buhg
спрашивает пароль 1й раз.
набираю пароль 1 й раз с ПК на Ubuntu: buhg
спрашивает пароль 2й раз.
набираю пароль 2й раз локального польщователя на сервере: buhg
после выдал страую ошибку: mount error(13): Permission denied
« Последнее редактирование: 08 Ноября 2013, 14:25:41 от Antiseptik »
oermolaev
Antiseptik,
ну вот, сделал это за вас: установил в VirtualBox Microsoft Windows Server 2003 R2 Standard Edition Service Pack 2 ни вводя регистрационного кода, ни вводя в домен, ни заводя никаких юзеров. Всё по умолчанию. Только пароль администратора задал. Сетевой адрес виртуальная машина получила по dhcp через сетевой мост.
так вот, по команде из хостовой машины:
$ sudo mount -t cifs //192.168.0.218/c$ /mnt/test -o username=Администраторвесь диск гостя успешно смонтировался:
$ ls /mnt/test/
AUTOEXEC.BAT Documents and Settings ntldr WINDOWS
bootfont.bin IO.SYS pagefile.sys wmpub
boot.ini MSDOS.SYS Program Files
CONFIG.SYS NTDETECT.COM System Volume Information
Chibiko
Пропишите в /etc/fstab
//192.168.0.1/1c /home/buhg/Base1C cifs username=buhg,password=123456,iocharset=utf8,file_mode=0777,dir_mode=0777 0 0Подключайте
mount -aДолжно сработать.
AnrDaemon
Хотите получить помощь? Потрудитесь представить запрошенную информацию в полном объёме.
Прежде чем [Отправить], нажми [Просмотр] и прочти собственное сообщение. Сам-то понял, что написал?…
Antiseptik
Поставил чистый пакет Ubuntu 13.10. Теперь при монтировании выдаётся ссобщение: «mount: невозможно примонтировать блочное устройство //192.168.0.12/1c только для чтения». Буду чесать репу дальше
Пользователь решил продолжить мысль 11 Ноября 2013, 12:52:14:
поменял уже ай-пишники и имена ПК и юзеров.
buh1@Buh1:~$ sudo mount -t cifs //192.168.50.2/1c /home/buh1/Base1C -o username=buh1
[sudo] password for buh1:
Password for buh1@//192.168.50.2/1c:
mount error(13): Permission denied
Refer to the mount.cifs( 8 ) manual page (e.g. man mount.cifs)
Пользователь решил продолжить мысль 11 Ноября 2013, 14:05:58:
Таки проблема с Windows Server 2003 R2. Пока не знаю где, разбираюсь. Потому как если монтит с WinXP — всё прекрастно моунтится
Пользователь решил продолжить мысль 11 Ноября 2013, 18:54:25:
1. Вообщем нашёл такую штуку, как отключение проверки SMB-пакетов на сервере: http://support.microsoft.com/kb/887429/ru
2. В локальных политиках безопасности «Сетевой доступ: модель совместного доступа и безопасности для локальных учетных записей» включил гостевой режим.
И как бы всё заработало, даже без проверки пароля на серваке (но скорее всего из-за второго пункта). Это, конечно, не решение моей проблемы, но даст мне время и возможность ещё подумать над этим…
Завтра буду пробовать автоматом маунтить черех фстаб=))
« Последнее редактирование: 11 Ноября 2013, 18:54:25 от Antiseptik »
- Печать
Страницы: [1] 2 Все Вверх
Есть Windows server в качестве файл сервера, на нем есть расшаренная папка SMB
Клиент на Винде спокойно ее монтирует, открывает, может в ней изменять содержимое
НО так же есть клиент на DEBIAN и при попытке монтирования, возникает Mount error(13) permission denied
На WinServer так же есть AD в котором есть пользователь Smb который создан для того, что бы монтировать папки
Пробовал следующие команды
sudo mount -t cifs -o username=smb,password=пароль //192.168.100.110/SMB /mnt/smb
Так же почитав об этой проблемме понял что можно добавить в команду домен (ping по имени домена проходит, если пинговать по доменому имени сервера тоже) тоже не помогло
mount -t cifs //win-share-hostname/share /mnt/win -o username=user,password=passwd,domain=xxx
где xxx — имя домена, а в случае использования локального пользователя — имя хоста
Добавление опций rw,file_mode=0777,dir_mode=0777 тоже никак не решило проблему
-
Вопрос заданболее года назад
-
985 просмотров