Nach Upgrade auf Lenny: Samba (ADS) will nicht mehr

[n***@pgs-info.de]

Hallo,

ich bin gerade etwas am Rudern.

Ich habe einen Samba-Server als AD-Mitglied (security = ADS), der lief
bis jetzt ganz wunderbar. Nach einem Upgrade auf Lenny, welches auch
sauber lief, habe ich ein Problem mit der Authentifikation.

Konkret: Die Shares sind noch zu sehen, nur beim Mounten (sei es manuell
oder über Logonskripte) fliegen die User raus, weil
Benutzername/Passwort nicht stimmen würden.

Ich hänge jetzt gerade ein wenig herum, weil ich auch nicht mehr so
recht weiß, wie ich mit der Fehlersuche weitermachen soll. Auch kurios:
ich habe noch einen zweiten Fileserver laufen (allerdings in einer
anderen Doamin, aber im gleichen AD), der direkt unter Lenny installiert
wurde, und der hat genau die gleiche Konfiguration, und bei dem läuft alles.

Ist das bei irgendwem auch passiert? Hat irgendwer einen Tip zur
Fehlersuche? Jede Hilfe ist willkommen.

Vielen Dank schon mal im Voraus!

[Patrick Stoesser]

Ein Nachtrag: Ich habe gerade einmal wbinfo -t und wbinfo -g versucht:
Ist beides ok (bei wbinfo -u steigt er immeraus, das war aber auch
früher schon so, das liegt wohl an der schieren Masse der User).

Dann mal kinit -V <BENUTZERNAME>@<REALM> versucht, und nach
Passwortabfrage kam dann auch "Authenticated to Kerberos v5".

[Patrick Stoesser]

Schon wieder etwas neues: Ich hatte in der smb.conf in den Shares "hosts
allow" gesetzt. Diese Einträge habe ich einmal auskommentiert (google
brachte mich darauf).

So, und nun kann ich mich zu Shares verbinden, aber nur dann, wenn sie
in irgendeiner Form schon einmal gemountet waren. Sei es als manuell
eingerichtetes Betzlaufwerk oder sei es, weil sie früher bereits auf
"browseable = yes" standen (manche waren das). Alle anderen Shares
werden nicht gefunden ("Der angegebene Pfad wurde nicht gefunden"). Auch
das Umstellen auf "browseable = yes" ändert daran nichts. Wenn ich mich
auf einem Windows-Client aber nur zum Server verbinde (\\<$FILESERVER>),
so kann ich die Shares sehen.

Ähm?

[Patrick Stoesser]

So, die Aufregung ist vorbei - es funktioniert alles wieder.

Ich habe etwas gemacht, was ich sonst nie mache: Alles relevante in /etc
gesichert, samba, winbind, krb5-* gepurgt, neu installiert, krb5.conf
und smb.conf zurückgespielt, den Server neu in das AD genommen, und
alles ist gut. Ich versuche jetzt noch, wie sich das mit den hosts
allow-Einträgen verträgt.

Dumme Sache, die eine Reproduzierbarkeit verunmöglicht: Ich habe das
alles von zuhause aus gemacht. Auf dem Server mit ssh, was ja kein
Problem ist, aber auf Clientseite ging es nur über einen
Windows-Terminalserver. Nun kann ich den aber nicht neustarten (keine
Rechte), aber mir fiel dann ein, dass manchmal Windows-Clients solch
seltsame Dinge wie "Netzwerkpfad nicht gefunden" nach einem Reboot nicht
mehr machen.

Also nochmal in die Stadt gefahren (dummerweise ist das VPN nämlich
gerade nicht verfügbar [keine Schuld] und siehe da: Alles ok.

Falls meine bisherigen Nachrichten etwas zu konfus waren, bitte ich dies
zu entschuldigen. Ist normalerweise nicht meine Art, aber heute mittag
war ich wirklich zeitweilig am Ende meines Lateins und sah schon die
User in meinem Nacken sitzen.

Grüße und gute Nacht, Patrick
--
Ich bin Beginner, Mann -
irgendwas fang ich immer an.

[Patrick Stoesser]

So, und eine Sache ist nunmehr definitiv: Sobald ich
hosts allow = localhost .<$DOMAIN>
oder aber auch
hosts allow = localhost <$DOMAIN>
auf Shareebene habe, tritt das Problem wieder auf, und zwar bei dem
Share, bei dem der Eintrag gesetzt ist. In [global]: genau das selbe,
nur auf allen Shares, global eben. Verwende ich IPs, ist aber alles ok.
Wie gesagt, bei Samba unter Etch ging das noch.

Grüße, Patrick

[Matthias Müller]

Post by Patrick Stoesser
So, und eine Sache ist nunmehr definitiv: Sobald ich
hosts allow = localhost .<$DOMAIN>
oder aber auch
hosts allow = localhost <$DOMAIN>
auf Shareebene habe, tritt das Problem wieder auf, und zwar bei dem
Share, bei dem der Eintrag gesetzt ist. In [global]: genau das selbe,
nur auf allen Shares, global eben. Verwende ich IPs, ist aber alles ok.

Das riecht doch nach nicht vorhandenem WINS (oder leerer lmhosts).

Ich hatte vor einigen Tagen, ein ähnliches Problem, dass ich nach einem
Serverwechsel auch den Share nicht mehr verbinden konnte. Die
Konstellation war hier : alter Sambaserver im gleichen Sub-Netzsegment
(229.49.1.0) wie Werkzeugmaschine mit Win 95, alles klappt. Neuer
Sambaserver im Backbone (172.19.2.0), WzM kann nicht auf den Share
zugreifen, IP, Gateway auf WzM alles stimmte. Drei Stunden Suche, Anruf
beim WzM-Hersteller, keine Lösung. Dann der Maschine eine lmhosts
spendiert, weil kein WINS vorhanden war. Sofort Verbindung zum Share
auf dem neuen Server.

Und vor einigen Monaten wurden massive Rekonfigurationen im Firmennetz
vorgenommen (Wechsel von Novell zu Windows 2k8-Cluster) und plötzlich
waren die Shares weg, bis wieder WINS-Server definiert waren.

Samba-Server waren zwar keine Linux- sondern AIX-Maschinen, aber die
Symptome gleichen sich.

Wer bessere Ideen hat, soll sich melden.

[Patrick Stoesser]

Post by Matthias Müller

Post by Patrick Stoesser
So, und eine Sache ist nunmehr definitiv: Sobald ich
hosts allow = localhost .<$DOMAIN>
oder aber auch
hosts allow = localhost <$DOMAIN>
auf Shareebene habe, tritt das Problem wieder auf, und zwar bei dem
Share, bei dem der Eintrag gesetzt ist. In [global]: genau das selbe,
nur auf allen Shares, global eben. Verwende ich IPs, ist aber alles ok.

Das riecht doch nach nicht vorhandenem WINS (oder leerer lmhosts).

Nö, WINS war da.

Aber, was wirklich superschräg war: Am nächsten Tag wieder Anrufe "kann
nicht auf meine Netzlaufwerke zugreifen".
Häh? Also Logging hochgedreht, und gesehen, dass es jetzt ein
Rechteproblem gibt. Und siehe da: Die Besitzer *aller* meiner Shares
waren (auf Dateisystemebene) wild durcheinandergewürfelt, und zwar
AD-weit. Kein Wunder, dass da nix mehr ging, es war unglaublich. Ich
habe sowas noch nie gesehen.
Nachdem ich stundenlang gechownt habe, gings wieder.

Ich habe jetzt einmal parallel einen Server unter Lenny neu aufgesetzt,
mit der gleichen Konfiguration: Läuft einwandfrei. Überhaupt keine
Probleme. Gut, zieh ich das Zeug eben am Wochenende um...

mfg, pgs