8
Smbclient funktioniert, mount -t cifs aber nicht
Hallo,
ich habe ein Ubuntu 14.04 LTS mit installierten cifs-utils, das die Freigabe "c$" von einem Windows 7 Rechner mounten soll.
Mit
smbclient 172.26.0.70/c$ -U linux%passwort
habe ich Zugriff und kann mit den Inhalt des Windows-Hauptverzeichnisses anschauen.
Hingegen kassiere ich bei
mount -t cifs172.26.0.70/c$ /media -o username=linux,password=passwort
die Meldung "mount error(13): Permission denied"
Benutzername und Passwort sind ja wohl gültig, sonst würde smbclient schon nicht funktionieren.
Von einem SLES11 aus funktioniert der mount-Befehl
apparmor wurde deinstalliert und die Maschine sicherheitshalber danach auch neugestartet.
Was unterscheidet den smbclient Aufruf von dem mount Aufruf oder worin könnten sich die beiden Linux-System hinsichtlich eines cifs-mount unterscheiden?
Danke für jeden Hinweis/Vorschlag,
Stefan
ich habe ein Ubuntu 14.04 LTS mit installierten cifs-utils, das die Freigabe "c$" von einem Windows 7 Rechner mounten soll.
Mit
smbclient 172.26.0.70/c$ -U linux%passwort
habe ich Zugriff und kann mit den Inhalt des Windows-Hauptverzeichnisses anschauen.
Hingegen kassiere ich bei
mount -t cifs172.26.0.70/c$ /media -o username=linux,password=passwort
die Meldung "mount error(13): Permission denied"
Benutzername und Passwort sind ja wohl gültig, sonst würde smbclient schon nicht funktionieren.
Von einem SLES11 aus funktioniert der mount-Befehl
apparmor wurde deinstalliert und die Maschine sicherheitshalber danach auch neugestartet.
Was unterscheidet den smbclient Aufruf von dem mount Aufruf oder worin könnten sich die beiden Linux-System hinsichtlich eines cifs-mount unterscheiden?
Danke für jeden Hinweis/Vorschlag,
Stefan
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 282506
Url: https://administrator.de/contentid/282506
Printed on: April 19, 2024 at 19:04 o'clock
8 Comments
Latest comment
Hallo Stefan,
ich würde so probieren:
Gruß,
Dani
ich würde so probieren:
mount -t cifs //server/share /media -o user=username,password=pw,domain=domäneGruß,
Dani
Hallo Dani,
Danke für den den Vorschlag, aber das funktioniert leider auch nicht.
Gruß,
Stefan
Danke für den den Vorschlag, aber das funktioniert leider auch nicht.
Gruß,
Stefan
- Poste bitte die Ausgabe bzw. Fehlermeldung.
- Gibt's den Parameter "password" überhaupt?
Hier die tolle Fehlermeldung:
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
"Permission denied" macht aber keinen Sinn, dass es mit dem identischen Befehl auf dem SLES funktioniert und auch mit smbclient.
Du kannst den Parameter "password" auch weglassen, dann wirst Du halt danach gefragt. Ist aber in einem Shellscript, dass beim Systemstart shares mounten soll, etwas unpraktisch.
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
"Permission denied" macht aber keinen Sinn, dass es mit dem identischen Befehl auf dem SLES funktioniert und auch mit smbclient.
Du kannst den Parameter "password" auch weglassen, dann wirst Du halt danach gefragt. Ist aber in einem Shellscript, dass beim Systemstart shares mounten soll, etwas unpraktisch.
Ist aber in einem Shellscript, dass beim Systemstart shares mounten soll, etwas unpraktisch.
Da gibt es aber praktischere Lösungen als ein Skript. - Anleitung. "Permission denied" macht aber keinen Sinn, dass es mit dem identischen Befehl auf dem SLES funktioniert und auch mit smbclient.
Ach das heißt gar nicht. Vor kurzem das selbe mit mount und fstab erlebt.Gruß,
Dani
/etc/fstab halte ich nicht für eine gute Idee, wenn es um das Mounten von Netzwerk-Share geht: Ist das Share nicht verfügbar, dann hängt die Kiste erst einmal und ich habe keinen Zugriff.
Stecke ich den mount Befehl in ein eigenes Start-Skript oder nach /etc/rc.local, dann kann ich sicher sein, dass ich entweder lokal oder per ssh auf die Maschine komme.
Und die Lösung für mein Problem habe ich inzwischen auch: Es gab eine Änderung im default Verhalten ab dem Kernel 3.8, das alte Verhalten kann man mit -o sec=ntlm wiedererhalten.
Gruß,
Stefan
Stecke ich den mount Befehl in ein eigenes Start-Skript oder nach /etc/rc.local, dann kann ich sicher sein, dass ich entweder lokal oder per ssh auf die Maschine komme.
Und die Lösung für mein Problem habe ich inzwischen auch: Es gab eine Änderung im default Verhalten ab dem Kernel 3.8, das alte Verhalten kann man mit -o sec=ntlm wiedererhalten.
Gruß,
Stefan
/etc/fstab halte ich nicht für eine gute Idee, wenn es um das Mounten von Netzwerk-Share geht: Ist das Share nicht verfügbar, dann hängt die Kiste erst einmal und ich habe keinen Zugriff.
undUnd die Lösung für mein Problem habe ich inzwischen auch: Es gab eine Änderung im default Verhalten ab dem Kernel 3.8, das alte Verhalten kann man mit -o sec=ntlm wiedererhalten.
Du hat den Link nicht gelesen, richtig? Der Zauberparameter heißt dev_net. Des Weitern solltest du sicherstellen, dass kein andere Benutzer an die Datei herankommt. Ist aber auch im Link alles beschrieben.Gruß,
Dani
Ich habe den Link gelesen und darin auf den ersten Blick die folgende Zeile gesehen:
"Then edit your /etc/fstab file (with root privileges) to add this line: "
Glaubst Du, ich vermute lediglich, dass in dem Artikel etwas über /etc/fstab steht?
"Then edit your /etc/fstab file (with root privileges) to add this line: "
Glaubst Du, ich vermute lediglich, dass in dem Artikel etwas über /etc/fstab steht?
