Ich bin vor Kurzem auf dieses Problem gestoßen. Normalerweise navigiere ich von einem Linux-Rechner aus über smb (also vom Dateimanager aus mit smb: ) durch einen freigegebenen Ordner im lokalen Netzwerk. Wenn ich jetzt versuche, auf die Verknüpfung zuzugreifen oder die Anmeldeinformationen erneut einzutippen, erhalte ich immer wieder das Dialogfenster, in dem ich nach Benutzer, Domäne und Passwort gefragt werde.
Daher habe ich versucht, den Speicherort manuell mit cisf-utils zu mounten. Dazu habe ich Folgendes getan:
sudo mount -t cifs //fileshare1/docs1/user/My\ Documents/shared/Francesco/ /home/frank/used_shared/ -o username=my_user,password=my_pass,domain=my_domain,gid=1000,uid=1000
Ich bekomme mount error(13): Permission denied
.
Ich bin absolut sicher, dass mein Benutzer Zugriff auf diesen Ordner hat, da ich von einem Windows-Rechner darauf zugreifen kann.
Auch wenn ich versuche, meinen persönlichen Ordner an diesem Speicherort über Folgendes bereitzustellen:
sudo mount -t cifs //fileshare1/docs5/francesco.azzarello/ /home/frank/mnt_folder -o username=my_user,password=my_pass,domain=my_domain,gid=1000,uid=1000
Ich kann problemlos darauf zugreifen.
Als Referenz verwende ich den 4.2.0-36-generischen Kernel und meine mount.cifs-Version ist 6.4
Irgendeine Idee, wie eine der beiden Methoden funktioniert?
AktualisierenBezüglich Ponsfrilus Antwort
Nummer 1: Die Option „Ausführlich“ gibt Folgendes zurück:
_mount.cifs kernel mount options: ip=xxx.xxx.xxx.xxx,unc=\\fileshare1\docs1,uid=1000,gid=1000,user=my_user,,domain=my_domain,prefixpath=user/My Documents/shared/Francesco/,pass=********
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)_
Nummer 2 ist im Grunde dasselbe:
_ mount.cifs kernel mount options: ip=xxx.xxx.xxx.xxx,unc=\\fileshare1\docs1,iocharset=utf8,file_mode=0777,dir_mode=0777,user=my_user,,domain=my_domain,prefixpath=user/My Documents/shared/Francesco/,pass=********
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)_
Und mit vers=2.1 hat sich nichts geändert:
_mount.cifs kernel mount options: ip=xxx.xxx.xxx.xxx,unc=\\fileshare1\docs1,vers=2.1,iocharset=utf8,file_mode=0777,dir_mode=0777,user=my_user,,domain=my_domain,prefixpath=user/My Documents/shared/Francesco/,pass=********
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)_
Was Nummer 4 betrifft, kann ich docs1 problemlos mounten, aber ich kann navigieren, um zum freigegebenen Ordner im Benutzer zu gelangen.
Antwort1
Ich bin ziemlich sicher, dass ich heute unter Ubuntu 16.10 auf genau dasselbe Problem gestoßen bin. Ich habe alle Vorschläge in diesem Thread mehrmals ausprobiert. Ich konnte mit Windows Server 2016 genau dieselbe Freigabe mounten und sie mit smbclient ( smbclient -U brainstrust //WINBOX01/shared
) durchsuchen. Ich habe sogar eine externe Anmeldeinformationsdatei ausprobiert.
Schließlich bin ich auf eine Lösung gestoßen – obwohl ich einen lokalen Benutzer für die Freigabe auf der Windows-Box erstellt hatte, war sie auch einer Domäne beigetreten. Im Grunde hat das Festlegen der Domäne auf die lokale Maschine -o domain=WINBOX01
mein Problem sofort behoben. Ich hinterlasse also hier einen Kommentar in der Hoffnung, dass er für jemanden da draußen nützlich ist.
Der vollständige Minimalbefehl, den ich verwendet habe, war:
sudo mount.cifs -v //WINBOX01/shared /home/geoff/winbox01 --verbose -o user=brainstrust,password=topsecret,domain=WINBOX01
Antwort2
Ich glaube, Sie haben den falschen Sicherheitstyp für den Server. Fehler 13 bedeutet, dass der Server Ihnen keinen Zugang gewährt.
Sie müssen den richtigen Sicherheitsmodus in Ihrem Mount-Befehl auswählen und eine Sec-Option über -o wie folgt hinzufügen[Referenz]:
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
Antwort3
Versuchen Sie, die Option „-v“ hinzuzufügen, um eine ausführliche Ausgabe zu erhalten:
sudo mount -v -t cifs //fileshare1/docs1/user/My\ Documents/shared/Francesco/ /home/frank/mnt_folder -o \ username=my_user,password=my_pass,domain=my_domain,gid=1000,uid=1000
Testen Sie mit diesen Optionen für den Mount-Befehl
iocharset=utf8,rw,Dateimodus=0777,Dir_modus=0777:
sudo mount -v -t cifs //fileshare1/docs1/user/My\ Documents/shared/Francesco/ /home/frank/mnt_folder -o username=my_user,password=my_pass,domain=my_domain,\ iocharset=utf8,rw,file_mode=0777,dir_mode=0777
Testen Sie mit Angabe der SMB-Versionsoption (vers=2.1), siehedas Samba-Wiki. Aus der Manpage von mount.cifs:
vers=
SMB-Protokollversion. Zulässige Werte sind:1.0 – Das klassische CIFS/SMBv1-Protokoll. Dies ist die Standardeinstellung.
2.0 – Das SMBv2.002-Protokoll. Dies wurde erstmals in Windows Vista Service Pack 1 und Windows Server 2008 eingeführt. Beachten Sie, dass die erste Version von Windows Vista einen leicht anderen Dialekt (2.000) sprach, der nicht unterstützt wird.
2.1 – Das SMBv2.1-Protokoll, das in Microsoft Windows 7 und Windows Server 2008R2 eingeführt wurde.
3.0 – Das SMBv3.0-Protokoll, das in Microsoft Windows 8 und Windows Server 2012 eingeführt wurde.
Versuchen Sie abschließend, nur die erste Freigabe zu mounten:
sudo mount -v -t cifs //fileshare1/docs1/ /home/frank/mnt_folder \ -o username=my_user,password=my_pass,domain=my_domain,\ iocharset=utf8,rw,file_mode=0777,dir_mode=0777
Jede ausführliche Ausgabe, die Sie weitergeben können, könnte hilfreich sein.
Antwort4
Das Hinzufügen der Option sec=ntlm
zum Mount-Befehl hat mein Problem behoben.
z.B:
sudo mount -t cifs -o username=administrator,password=123456,sec=ntlm //ip/eeshare /mnt/eeshare/