Tach Leute, hab hier ein Problem, bei dem ich nicht mehr weiter weiß. Ich möchte mit Hilfe von Samba (Suse 8.2, also Samba 2.2.7a) Freigaben exportieren. Das funktioniert im Prinzip auch, habe das schon x-mal ohne Probleme gemacht. In diesem Falle aber tritt folgendes Phänomen auf: wenn ein Windows-2k-Client gestartet wird, zeigt er die Fehlermeldung: Ein gleicher Name wird im Netzwerk bereits verwendet. Netzwerkverbindung kann daher nicht gestartet werden (sinngemäß). Die Netzwerkumgebung ist danach nicht verfügbar. Fahre ich dagegen Samba zuerst runter, starte dann den Windows-Client, und danach Samba, so funktioniert alles, einschließlich der Zugriffe auf den Samba-Server Im Netz befinden sich zwei Arbeitsgruppen (firma und fibu), der Samba-Server ist Teil der Gruppe fibu. Im restlichen Netz befinden sich bunt verstreut Macs, Windows-2000- und XP-Kisten. Auf dem Samba-Server selbst läuft außerdem - ohne Probleme - netatalk. Hier noch die smb.conf: [global] workgroup = Fibu netbios name = Fibu server string = Windows NT 4.0 os level = 0 preferred master = no domain master = no local master = no unix extensions = Yes encrypt passwords = Yes log level = 1 syslog = 0 socket options = SO_KEEPALIVE IPTOS_LOWDELAY TCP_NODELAY wins support = No veto files = /*.eml/*.nws/riched20.dll/*.{*}/ security = user [Danach folgen die Shares] Hat wer ne Idee, wonach ich suchen könnte? Danke. Andy -- Andreas Feile www.feile.net
Andreas Feile wrote:
Tach Leute,
hab hier ein Problem, bei dem ich nicht mehr weiter weiß.
Ich möchte mit Hilfe von Samba (Suse 8.2, also Samba 2.2.7a) Freigaben exportieren. Das funktioniert im Prinzip auch, habe das schon x-mal ohne Probleme gemacht. In diesem Falle aber tritt folgendes Phänomen auf: wenn ein Windows-2k-Client gestartet wird, zeigt er die Fehlermeldung: Ein gleicher Name wird im Netzwerk bereits verwendet. Netzwerkverbindung kann daher nicht gestartet werden (sinngemäß). Die Netzwerkumgebung ist danach nicht verfügbar. Fahre ich dagegen Samba zuerst runter, starte dann den Windows-Client, und danach Samba, so funktioniert alles, einschließlich der Zugriffe auf den Samba-Server
Im Netz befinden sich zwei Arbeitsgruppen (firma und fibu), der Samba-Server ist Teil der Gruppe fibu. Im restlichen Netz befinden sich bunt verstreut Macs, Windows-2000- und XP-Kisten. Auf dem Samba-Server selbst läuft außerdem - ohne Probleme - netatalk.
Hier noch die smb.conf:
[global] workgroup = Fibu netbios name = Fibu server string = Windows NT 4.0 os level = 0 preferred master = no domain master = no local master = no unix extensions = Yes encrypt passwords = Yes log level = 1 syslog = 0 socket options = SO_KEEPALIVE IPTOS_LOWDELAY TCP_NODELAY wins support = No veto files = /*.eml/*.nws/riched20.dll/*.{*}/ security = user [Danach folgen die Shares]
Hat wer ne Idee, wonach ich suchen könnte?
Danke. Andy
aendere den "netbios name" mal in "Fibu Linux" mfg -- ---------------------------------------- Markus Heinze Internet: http://www.existand.de E-Mail : M.Heinze@existand.de Telephon: 03464/569787 Fax : 03464/569786 ----------------------------------------
Am 08.09.2003 10:06 Uhr schrieb "Andreas Feile" unter
Im Netz befinden sich zwei Arbeitsgruppen (firma und fibu), der Samba-Server ist Teil der Gruppe fibu. Im restlichen Netz befinden sich bunt verstreut Macs, Windows-2000- und XP-Kisten. Auf dem Samba-Server selbst läuft außerdem - ohne Probleme - netatalk.
Hier noch die smb.conf:
[global] workgroup = Fibu netbios name = Fibu server string = Windows NT 4.0 os level = 0 preferred master = no domain master = no local master = no unix extensions = Yes encrypt passwords = Yes log level = 1 syslog = 0 socket options = SO_KEEPALIVE IPTOS_LOWDELAY TCP_NODELAY wins support = No veto files = /*.eml/*.nws/riched20.dll/*.{*}/ security = user
na, sieht ja so aus, als ob dein Problem gelöst wurde (netbios name). ABER ... da du Netatalk NOCH ohne Probleme einsetzt, würde ich dir dringend dazu raten, die veto files anzupassen. Die Samba-User haben mit deiner Konfig vollen Zugriff auf die Resource-Fork von Netatalk. Hier meine veto files: veto files = /*.eml/*.nws/riched20.dll/*.{*}/.AppleDB/.AppleDesktop/.AppleDouble/TheVolum eSettingsFolder/Network Trash Folder/Trash/TheFindByContentFolder/:2eDS_Store/Temporary Items/ Ich sperre auch den Zugriff von OSX-Dateien (:2eDS_Store). Gruss Michael -- Bitte die Etikette beachten: http://www.suse-etikette.de.vu/etikette.html Bitte Realnamen angeben, kein Vollquoting, kein Html, PGP oder Visitenkarten benutzen. Signatur mit "-- " abtrennen, bei Antworten "Re: " voranstellen, sonst nichts.
Servus Michael, Michael Grundmann, Dienstag, 9. September 2003 06:58:
na, sieht ja so aus, als ob dein Problem gelöst wurde (netbios name). ABER ... da du Netatalk NOCH ohne Probleme einsetzt, würde ich dir dringend dazu raten, die veto files anzupassen. Die Samba-User haben mit deiner Konfig vollen Zugriff auf die Resource-Fork von Netatalk. Hier meine veto files: veto files = /*.eml/*.nws/riched20.dll/*.{*}/.AppleDB/.AppleDesktop/.AppleDouble/T heVolum eSettingsFolder/Network Trash Folder/Trash/TheFindByContentFolder/:2eDS_Store/Temporary Items/
Mensch, da krieg ich noch ganz nebenbei einen Tip, noch bevor es überhaupt zu einem Problem gekommen ist. In Bezug auf netatalk hatte ich allerdings nicht die ganze Wahrheit geschrieben: netatalk und samba exportieren _auf_diesem_Rechner unterschiedliche Verzeichnisse. Daher können sie sich nicht in die Quere kommen. Meinen Doppel-Export-Testrechner habe ich woanders rumstehen. Und auf diesen werde ich Deine Veto-File-Liste diese Tage mal übertragen. Frage noch: hast Du in Deiner smb.conf delete veto files = Yes gesetzt? Wäre doch eigentlich sinnvoll, oder? -- Andreas Feile www.feile.net
Am 09.09.2003 7:53 Uhr schrieb "Andreas Feile" unter
Meinen Doppel-Export-Testrechner habe ich woanders rumstehen. Und auf diesen werde ich Deine Veto-File-Liste diese Tage mal übertragen.
Frage noch: hast Du in Deiner smb.conf delete veto files = Yes gesetzt? Wäre doch eigentlich sinnvoll, oder?
Puh - mach das aber nicht auf dem Doppel-Export-Testrechner. Dann ist die Resource-Fork, der Network Trash Folder usw. gleich mal wech und nix iss mit AFP. Also, lass das besser mal :) Gruß Michael -- make it run, make it safe, make it fast
Michael Grundmann, Dienstag, 9. September 2003 19:39:
Frage noch: hast Du in Deiner smb.conf delete veto files = Yes gesetzt? Wäre doch eigentlich sinnvoll, oder?
Puh - mach das aber nicht auf dem Doppel-Export-Testrechner. Dann ist die Resource-Fork, der Network Trash Folder usw. gleich mal wech und nix iss mit AFP.
Also vielleicht verstehe ich dann was nicht... Das führt doch dann dazu, daß ich via Samba manche Verzeichnisse nicht löschen kann - eben dann, wenn da noch Veto-Krams drin rumliegt, oder? Und: Dann issie eben wech, die Resource-Fork. Wollte das Verzeichnis ja eh löschen. Ich hatte genau diesen Fall heute: Konnte via Samba von einem Windows-Rechner ein Verzeichnis nicht löschen. Ging einfach nicht. Vom Mac aus gings dann einwandfrei. Hab dann nicht weiter rumprobiert, aber dachte mir im stillen, delete veto files = yes könnte ja die Lösung sein... Gruß. Andy -- Andreas Feile www.feile.net
Am 10.09.2003 0:03 Uhr schrieb "Andreas Feile" unter
Also vielleicht verstehe ich dann was nicht... Das führt doch dann dazu, daß ich via Samba manche Verzeichnisse nicht löschen kann - eben dann, wenn da noch Veto-Krams drin rumliegt, oder?
Jepp - aber aus dem Grund, weil sie dem WinSys erst gar nicht angezeigt werden. Bei diesen .dll-Dateien mag das vielleicht sinn machen (ich meine jetzt das gleichzeitige löschen), aber ich nutze hier die veto files um spezielle Ordner, die unbedingt vom Mac gebraucht werden, zu verstecken. So kann hinsichtlich Macintosh-Umgebung nichts schief laufen.
Und: Dann issie eben wech, die Resource-Fork. Wollte das Verzeichnis ja eh löschen.
Wieso willst du die Resource-Fork löschen???? In der Resource-Fork stehen z.b. Creator und Type der Datei drin. Wenn diese wech ist kannst du keine Datei mehr ohne weiteres öffnen. Wie willst du wissen, ob du jetzt ein Quark-Dokument vor dir hast oder ein Word-Dokument. Klar, wenn sicher gestellt ist, dass die Mac-User immer ein Suffix an die Datei anhängen, kannst du eh das AppleDouble abschalten (in der AppleVolumes.default: options:noadouble). Aber dann bewegst du dich in einer unsicheren Umgebung.
Ich hatte genau diesen Fall heute: Konnte via Samba von einem Windows-Rechner ein Verzeichnis nicht löschen. Ging einfach nicht. Vom Mac aus gings dann einwandfrei. Hab dann nicht weiter rumprobiert, aber dachte mir im stillen, delete veto files = yes könnte ja die Lösung sein...
Wie sehen die Zugriffsrechte auf deinem Double-Test-Rechner aus? Welcher User greift via AFP auf den Linux-Rechner zu und welcher ist bei Samba freigegeben? Die Zugriffsrechte bei AFP sind ganz anders, als bei Unix oder Samba. Hier zählt das StickyBit (heisst doch so ;), oder? ) des Ordners. Ist dieser Ordner fuer User X freigegeben, zählt das auch für den kompletten Inhalt. Gruß Michael -- ROTFL = Rolling On The Floor, Laughing = Auf dem Boden wälzen, lachend. SCNR = Sorry, Could Not Resist = Sorry, Ich konte nicht widerstehen. AFAIK = As Far As I Know = So weit ich weis|BTW = By The Way = Nebenbei bemerkt IMHO = In My Humble Opinion = meiner bescheidenen Meinung nach
Michael Grundmann, Mittwoch, 10. September 2003 06:39:
Jepp - aber aus dem Grund, weil sie dem WinSys erst gar nicht angezeigt werden. Bei diesen .dll-Dateien mag das vielleicht sinn machen (ich meine jetzt das gleichzeitige löschen), aber ich nutze hier die veto files um spezielle Ordner, die unbedingt vom Mac gebraucht werden, zu verstecken. So kann hinsichtlich Macintosh-Umgebung nichts schief laufen. [...viel nützliches...]
Wieder was über die Netatalk-Sache gelernt. Ich muß mich noch näher damit auseinandersetzen. Und vermutlich hast Du Recht - ich laß das erst mal mit dem Löschen von Veto Files. Danke+Gruß. Andy -- Andreas Feile www.feile.net
participants (3)
-
Andreas Feile -
Markus Heinze -
Michael Grundmann