[Anm. vorweg.: Ich habe das Problem bereits gelöst, aber poste es trotzdem hier - da es mir eine schlaflose Nacht bereitet hat die ich vielleicht jemand anderem ersparen kann,]
Hallo zusammen,
nachdem mein Home Server (openSUSE 13.1) mittlerweile eine Uptime von fast 500 Tagen erreicht hatte Stand mal wieder ein Schwung Updates samt Neustart an. Unter den Updates befand sich auch ein Samba Server Update (4.1.17-3.30.1-3375-SUSE-oS13.1-x86_64). Nach dem Serverneustart hatte ich jedoch plötzlich keinen Zugriff mehr auf die Netzlaufwerke, nmb und smb liefen aber scheinbar problemlos. Einzige Auffälligkeit (die auch weiterhin besteht, aber mit dem Problem nichts zu tun hatte) ist folgende Meldung in /var/log/samba/log.smb:
Das die Meldung "Error was No such file or directory" eigentlich unbegründet ist zeigt folgendes:
allerdings hat nur Root schreibrechte auf die pid-Files. Also liegt die Ursache womöglich darin das nmbd/smbd keinen Schreibzugriff haben und die Dateien somit auch nicht löschen können. Lustigerweise verschwinden die .pid Files aber wenn ich smbd/nmbd beende.
Bemerkenswerterweise konnte ich in den Windowsclients immer noch die Liste der Shares abrufen durch Eingabe von "\\<servername\" in der Adressleiste des Explorers. Auch der Zugriff auf frei zugängliche Shares war weiterhin gegeben, lediglich die Netzlaufwerke, die eine Authentifizierung auf Benutzerebene erforderten waren nicht zugänglich. Beim Versuch diese Freigaben zu öffnen erschien in Win7 der Credentials-Prompt und fragte nach Benutzername und Passwort. Ein Firewallproblem war also praktisch auszuschliessen.
Die Googlesuche förderte dann eine Menge esoterischer Lösungen (Anpassung der Sicherheitsrichtlinien für SMB Authentifizerung, Windows Registry Hacks etc. zutage). Da Windows aber mit den bisherigen Einstellungen funktioniert hatte und die einzige Veränderung im Update des Sambaservers bestand, musste die Ursache auch hier zu finden sein. Während meiner Versuche bemerkte ich weitere Auffälligkeiten:
Normalerweise konnte ich mich bisher mit folgenden Daten unter Windows 7 gegen den Sambaserver authentifizieren:
Benutzer: \\<servername>\benutzername
Passwort: ********
Dies führte sofort zur Meldung "Zugriff verweigert". Wenn ich aber die Credentials wie folgt eingab:
Benutzer:\\<servername>.<domainname>\benutzername
Passwort: ********
Geschah erstmal nichts - der Explorer schien mit Verbindungsversuchen beschäftigt zu sein die dann aber nach schätzungsweise 15 Sekunden mit folgender Meldung endeten:
"Error code: 0X80070035 The network path was not found."
Da ich das Share durch Doppelklick im Explorer geöffnet hatte, schien es doch sehr seltsam das der Pfad ungültig sein sollte. Nach langem Herumprobieren wandte ich mich wieder dem Server zu, auf dem dann auch irgendwann neue Meldungen in den Logs auftauchten:
Diese Meldunge war es dann auch, die mich schliesslich auf die richtige Fährte brachte. Offenbar war die Ursache für das Problem ein Konflik zwischen dem Domänennamen des Samba Servers und dem in der smb.conf gesetzten NetBIOS-Namen bzw. -Alias.
Die Lösung besteht darin folgende Zeilen in der /etc/samba/smb.cnf anzupassen:
/etc/samba/smb.cnf - ALT
/etc/samba/smb.cnf - NEU
Und siehe da die Shares sind wieder zugreifbar. Angenehmerweise authentifiziert sich Windows im Gegensatz zu früher nun automatisch, mit Benutzernamen und Passwort des angemeldeten Users.
Hallo zusammen,
nachdem mein Home Server (openSUSE 13.1) mittlerweile eine Uptime von fast 500 Tagen erreicht hatte Stand mal wieder ein Schwung Updates samt Neustart an. Unter den Updates befand sich auch ein Samba Server Update (4.1.17-3.30.1-3375-SUSE-oS13.1-x86_64). Nach dem Serverneustart hatte ich jedoch plötzlich keinen Zugriff mehr auf die Netzlaufwerke, nmb und smb liefen aber scheinbar problemlos. Einzige Auffälligkeit (die auch weiterhin besteht, aber mit dem Problem nichts zu tun hatte) ist folgende Meldung in /var/log/samba/log.smb:
Code:
[2015/05/09 14:02:41.951165, 0] ../lib/util/pidfile.c:153(pidfile_unlink)
Failed to delete pidfile /run/samba/smbd.pid. Error was No such file or directory
Das die Meldung "Error was No such file or directory" eigentlich unbegründet ist zeigt folgendes:
Code:
/etc/samba # ls -l /run/samba/
total 8
drwxr-xr-x 3 root root 60 May 9 02:05 ncalrpc
drwxr-xr-x 2 root root 60 May 9 14:02 nmbd
-rw-r--r-- 1 root root 6 May 9 14:02 nmbd.pid
-rw-r--r-- 1 root root 6 May 9 14:02 smbd.pid
allerdings hat nur Root schreibrechte auf die pid-Files. Also liegt die Ursache womöglich darin das nmbd/smbd keinen Schreibzugriff haben und die Dateien somit auch nicht löschen können. Lustigerweise verschwinden die .pid Files aber wenn ich smbd/nmbd beende.
Bemerkenswerterweise konnte ich in den Windowsclients immer noch die Liste der Shares abrufen durch Eingabe von "\\<servername\" in der Adressleiste des Explorers. Auch der Zugriff auf frei zugängliche Shares war weiterhin gegeben, lediglich die Netzlaufwerke, die eine Authentifizierung auf Benutzerebene erforderten waren nicht zugänglich. Beim Versuch diese Freigaben zu öffnen erschien in Win7 der Credentials-Prompt und fragte nach Benutzername und Passwort. Ein Firewallproblem war also praktisch auszuschliessen.
Die Googlesuche förderte dann eine Menge esoterischer Lösungen (Anpassung der Sicherheitsrichtlinien für SMB Authentifizerung, Windows Registry Hacks etc. zutage). Da Windows aber mit den bisherigen Einstellungen funktioniert hatte und die einzige Veränderung im Update des Sambaservers bestand, musste die Ursache auch hier zu finden sein. Während meiner Versuche bemerkte ich weitere Auffälligkeiten:
Normalerweise konnte ich mich bisher mit folgenden Daten unter Windows 7 gegen den Sambaserver authentifizieren:
Benutzer: \\<servername>\benutzername
Passwort: ********
Dies führte sofort zur Meldung "Zugriff verweigert". Wenn ich aber die Credentials wie folgt eingab:
Benutzer:\\<servername>.<domainname>\benutzername
Passwort: ********
Geschah erstmal nichts - der Explorer schien mit Verbindungsversuchen beschäftigt zu sein die dann aber nach schätzungsweise 15 Sekunden mit folgender Meldung endeten:
"Error code: 0X80070035 The network path was not found."
Da ich das Share durch Doppelklick im Explorer geöffnet hatte, schien es doch sehr seltsam das der Pfad ungültig sein sollte. Nach langem Herumprobieren wandte ich mich wieder dem Server zu, auf dem dann auch irgendwann neue Meldungen in den Logs auftauchten:
Code:
../source3/nmbd/nmbd_become_lmb.c:533(become_local_master_browser)
become_local_master_browser: Error - cannot find server <servername>.<domainname> in workgroup <workgroupname> on subnet 192.168.1.1
Diese Meldunge war es dann auch, die mich schliesslich auf die richtige Fährte brachte. Offenbar war die Ursache für das Problem ein Konflik zwischen dem Domänennamen des Samba Servers und dem in der smb.conf gesetzten NetBIOS-Namen bzw. -Alias.
Die Lösung besteht darin folgende Zeilen in der /etc/samba/smb.cnf anzupassen:
/etc/samba/smb.cnf - ALT
Code:
...
netbios name = <servername>.<domainname>
netbios aliases = <servername>
...
/etc/samba/smb.cnf - NEU
Code:
...
# AUSKOMMENTIEREN:
# netbios name = <servername>.<domainname>
# netbios aliases = <servername>
# HINZUFÜGEN:
disable netbios = yes
...
Und siehe da die Shares sind wieder zugreifbar. Angenehmerweise authentifiziert sich Windows im Gegensatz zu früher nun automatisch, mit Benutzernamen und Passwort des angemeldeten Users.