ubuntuusers.de

Hallo allerseits,

ich kann seit kurzem nicht mehr auf meine Samba-Freigaben meines Servers zugreifen. Hier meine Konfiguration:

Server: Ubuntu Server 9.10; Samba 3.4.0 Client: Ubuntu Desktop 9.10

Die Freigaben sind mit Passwort geschützt. Der Benutzer der Freigabe existiert sowohl auf dem Server, als auch auf dem Client und beide haben das selbe Passwort. Im Passwort ist "alles vertreten", also Groß-, Kleinschreibung, Zahlen und Sonderzeichen. Die Freigabe soll via Shell (mount.cifs) gemountet werden.

Wie gesagt, ich habe nichts (bewusst) an meiner Konfiguration verändert und bisher hat es auch immer funktioniert. Nun bekomme ich immer ein "Permission denied". Wenn ich das Passwort des Benutzers auf dem Server auf eins ohne Sonderzeichen ändere, kann ich diese auch wieder mounten.

Was ist da los? Kann mir jemand helfen? Wie gesagt, bis vor kurzem hat das alles noch wunderbar geklappt.

Danke im Vorraus, Gruß, EffeX7

Sind da Sonderzeichen drin, die von der Shell interpretiert werden könnten (vor allem $)? Gibst du das Passwort interaktiv oder per Parameter an?

MfG Dalai

Hallo Dalai,

erst mal danke für die schnelle Antwort.

Das Passwort wird nicht via Parameter oder Credentials Datei eingegeben, sondern interaktiv "erfragt". Ich meine die Sonderzeichen im Passwort sollten nicht von der Shell ausgewertet werden ... und selbst wenn dort Sonderzeichen drin sind die von der Shell ausgewertet werden können, warum jetzt und nicht vorher schon? Wie gesagt, genau diese Konfiguration hat bis vor kurzem funktioniert.

Gruß, EffeX7

OK, dann schau mal in die Logfiles von Samba in /var/log/samba/; wichtig sind log.<client> und log.smbd. Ein "Permission denied" kann auch von unpassend gesetzten Rechten des Mountpunkts herrühren; überprüf die mal.

MfG Dalai

Ich weiß, dass ein "Permission Denied" auch von falsch gesetzten Dateirechten kommen kann. Aber in meinem Fall dürfte das wohl nicht zutreffen! Denn sobald ich das Benutzerpasswort auf dem Server ändere (ohne Sonderzeichen), funktioniert es!

In der log.client steht das hier:

[2010/04/08 17:21:03,  1] smbd/service.c:676(make_connection_snum)
  create_connection_server_info failed: NT_STATUS_WRONG_PASSWORD

In der log.smbd steht nichts, was auf einen Fehler hindeutet.

Ich hatte auch schon mal nach dem obigen Fehler gegoogelt, aber immer nur was gefunden in Bezug auf Windows Clients.

Ich bin ratlos ...

EffeX7 schrieb:

Ich weiß, dass ein "Permission Denied" auch von falsch gesetzten Dateirechten kommen kann. Aber in meinem Fall dürfte das wohl nicht zutreffen! Denn sobald ich das Benutzerpasswort auf dem Server ändere (ohne Sonderzeichen), funktioniert es!

Ja, sorry, das schriebst du im OP ja schon. Insofern - und auch wegen des Logeintrags - kann man wohl von einem Passwortproblem ausgehen.

Öhm, wie sieht es mit Zeichensatz und Tastaturlayout aus? Kannst du auf der Konsole das Passwort korrekt eingeben?

MfG Dalai

Ich kann das Passwort normal tippen. Ich kann mich auch via ssh zum Server verbinden (mit dem selben Benutzer/Passwort, mit dem es dann via Samba nicht klappt). "locale" auf allen Rechnern (Server, Client) gibt überall UTF-8 aus.

Das alles gilt übrigens auch für verschiedenen Rechner als Clients (aber immer mit Ubuntu 9.10).

Und es bleibt weiterhin bestehen: Ich bin mir keiner Konfigurationsänderung bewusst.

Mmh, dann hat wohl irgendein Update - sofern du welche eingespielt hast - irgendwas geändert. Was das nun konkret ist: im Moment keine Ahnung.

Probier mal

smbclient -U <user> //rechner/freigabe

Mal sehen, ob nur mount.cifs betroffen ist.

MfG Dalai

Irgend ein komisches Update wird es sicher gewesen sein. Auf dem Server werden diese automatisch installiert und auf den Clients mache ich das regelmäßig "per Hand" ...

Das mit smbclient klappt auch nicht. Die Fehlermeldung ist die folgende:

Server not using user level security and no password supplied.
tree connect failed: NT_STATUS_WRONG_PASSWORD

Der zweite Teil ist ja bekannt, aber was soll mir der erste sagen? In meiner smb.conf ist unter "global" security Ebene auf "share" gesetzt (also nicht auf user) ... aber wie gesagt, hier habe ich nichts geändert und es hat vorher auch geklappt ☹

... Wenn ich übrigens das Passwort ändere klappt es mit smbclient immer noch nicht, aber die Fehlermeldung ändert sich:

Server not using user level security and no password supplied.
Server requested LANMAN password (share-level security) but 'client lanman auth' is disabled
tree connect failed: NT_STATUS_ACCESS_DENIED

Dann probier's mal mit security = user. Ich kann mir vorstellen, dass ein Update irgendwas am Verhalten von Samba geändert hat. Dass es vorher funktionierte, sagt ja erstmal nicht wirklich was aus 😉. Die Einstellung security = share halte ich heutzutage sowieso für überflüssig, weil man sowas nur für Win9x-Clients braucht, die keine echte Nutzerverwaltung haben.

MfG Dalai

So wirklich hat das auch nicht geholfen.

Mit smbclient kann ich nun auf die Freigabe zugreifen. Aber mit mount.cifs immer noch nicht (selber Fehler auf Client Seite, aber lediglich ein

[2010/04/09 19:15:20,  1] smbd/service.c:1241(close_cnum)
  192.168.10.26 (192.168.10.26) closed connection to service effex7

auf Server Seite).

Allerdings bin ich mir nicht sicher, ob ich das mit der security Option richtig verstanden habe! Ich dachte immer, dass man durch "security = share" für jede Freigabe die Rechte für diese Freigabe expliziet bei dieser regeln kann (also eben User x darf lesen, y lesen / schreiben alle anderen gar nichts ...). Ist dies durch "security = user" nicht ausgehebelt?

Ich danke Dir auf jeden Fall für Deine Hilfe so weit ... aber ich bin immer noch am verzweifeln 😀

Benutz mal zum Mounten

mount -t cifs

statt mount.cifs.

EffeX7 schrieb:

Ich dachte immer, dass man durch "security = share" für jede Freigabe die Rechte für diese Freigabe expliziet bei dieser regeln kann (also eben User x darf lesen, y lesen / schreiben alle anderen gar nichts ...). Ist dies durch "security = user" nicht ausgehebelt?

Nö, ist es nicht. Die Manpage zu smb.conf sagt zum Parameter security:

 SECURITY = SHARE

           When clients connect to a share level security server they need not log onto the server with a valid
           username and password before attempting to connect to a shared resource [...]

 SECURITY = USER

           This is the default security setting in Samba 3.0. With user-level security a client must first "log-on"
           with a valid username and password [...]

Es stehen noch mehr Erklärungen zu den Varianten, aber ich hab mir mal das Fullquote gespart, weil du ja selber nachschauen kannst mit man smb.conf (Suchen nach security, Suche starten geht mit dem Slash, nächsten Treffer gibt's mit Taste N). Davon abgesehen gibt's noch mehr Möglichkeiten, bestimmten Usern versch. Zugriff zu gewähren (valid users, write list etc) und im Dateisystem kann man das auch noch regeln ☺.

MfG Dalai

Der Security-Level Security = share geht AFAIK nur noch in Verbindung mit der - ebenfalls veralteten und unsicheren - Lanman-Authentifizierung. Ein Grund mehr, ihn nicht zu verwenden.

Wenn nur die Sonderzeichen im Passwort Probleme machen, kann ich mir vorstellen, dass es mit dem verwendeten Zeichensatz zusammenhängt. Kann es sein, dass dieser auf dem Server und Client nicht (mehr) identisch ist?

Ich glaube nicht, dass mount.cifs und mount -t cifs unterschiedlich reagieren, denn mount -t cifs verwendet ja intern mount.cifs. Doch Probieren kann nichts schaden...

Gruß - Max-Ulrich

Am Ende kann es eigentlich nur der Zeichensatz sein. Aber aktiv habe ich daran nichts geändert. Eine ssh Verbindung klappt auch einwandfrei (selber Benutzername / Passwort). Und "locale" gibt mir für alle Systeme UTF-8 aus.

Ich bin echt am verzweifeln ☹

Mir is übrigens aufgefallen das (trotz hohem Log-Level) momentan keiner meiner Fehlversuche in dem samba Logs des Servers ankommt.

Für weitere Hinweise bin ich echt dankbar!

Hast du den Samba nach Änderungen der smb.conf neu geladen (reload) oder gar neu gestartet (restart)?

Gib mal bitte den von dir verwendeten Befehl zum Mounten. Denn wenn smbclient problemlos funktioniert, muss ja woanders was faul sein.

MfG Dalai