Linux File Server mit Mac OS X nutzen

[Horst Schulz]

Hi,

folgendes Problem :

Ich hab in nem Büro nen alten PC zu nem File Server umfunktioniert
mittels Debian Woody. Darauf läuft halt Samba damit die restlichen
Windows Kisten darauf zugreifen können. Nun hat sich der Chef nen Mac
mit OS X geholt und will ebenfalls auf den Server zugreifen. Ich habs
versucht mittels smb und dem Server verbinden. Da hab ich dann die
korrekte IP angegeben und auch den Mac User auf der Linuxkiste
eingerichtet. Da bekam ich dann die Meldung das Dateien nicht lesbar
waren und ich nun immernoch nicht auf die freigegebenen Verzeichnisse
zugreifen konnte. Nach mehreren erfolglosen Versuchen und kam ich damit
nicht wirklich voran. Dann probierte ich es mittels NFS nur da zickte
dann der portmap vom OS X rum und ich bekam ebenfalls keine Verbindung
zum File Server.

Ich hatte bis dahin diverse HowTos und Manuals gelsen die google mir
anbot, aber so richtig half das alles nicht...:(

Hat hier wer noch ne Idee was man noch machen könnte !?

[Thomas Kaiser]

Post by Horst Schulz
Hat hier wer noch ne Idee was man noch machen könnte !?

Netatalk wäre der Königsweg (weil spricht das Hausprotokoll der Macs für
FileSharing) aber das wird in Deiner Situation mit Rest der Mannschaft
per Samba angebunden auch keinen Spaß machen (siehe Archiv und Netatalk-
FAQ bzgl. Locking-Problematik)

Wenn Du mit SMB und 'nem Mac halbwegs glücklich werden willst, dann
achte darauf, daß Du auf dem Server mindestens Samba 3 im Einsatz hast
(das kann UTF-8 und das gehört dann auch so eingestellt -- blöd, falls
Ihr aktuell andere Settings haben solltet, dann hilft nur ein Blick zu

<http://j3e.de/linux/convmv/man/>

Einen Mischbetrieb von NFS und SMB auf dem Server kannst Du Dir eh in
die Haare schmieren, weil dann vom Mac aus in jedem Fall Dateinamen als
"UTF-8 decomposed" auf dem Server landen, Samba 3.x aber wenn dann
"UTF-8 precomposed" will (und vorherige Samba-Versionen noch nicht mal
wissen, wie man Unicode oder UTF-8 buchstabiert -- sprich, Du hast da
blitzschnell ein heilloses Dateinamenschaos angerichtet.)

BTW: Warum Debian Woody und nicht das aktuelle?

Ach ja, und warum überhaupt Linux? Die sauberste Lösung im Lowcost-
Bereich für gemischte Windows- und Mac-Zugriffe auf Dateiserver ist
entweder eine MacOS X Kiste (weil hat AppleFileServer und Samba 3.x an
Bord mit Patches bzgl. Interaktion zwischen beiden) oder eine Windows-
Schüssel mit ExtremeZ-IP 4/5 oder MacServer IP (ab Version 9).

Lacie hat sowas als NAS-Lösung im Programm (also inkl. Windows und
ExtremeZ-IP -- aber das kriegt man nicht mit) aber LaCie kauft man ja
eigentlich schon alleine aus Erfahrung nicht...

Schwierig, schwierig...

Gruss,

Thomas

[Horst Schulz]

Post by Thomas Kaiser
BTW: Warum Debian Woody und nicht das aktuelle?

Weil das System bisher gut läuft und ich nicht den Bedarf für nen Update
sah...:) Hab da auch Bekannte gefragt die Admins hauptberuflich machen,
ob ich das updaten solle und die Mehrheit meinte, wenns läuft lass es.

Post by Thomas Kaiser
Ach ja, und warum überhaupt Linux?

Weil am Anfang nur Windows Kisten darauf zugriffen und erst seit ca. 3
Monaten der Kollesch den Mac hat. Dazu kommt noch das auf dem Server ne
Groupware läuft damit sie im Büro ihre Termine und so besser verwalten
können. Das hatte sich halt aus ner Spielerei während meines Praktikums
dort entwickelt.

Ich werd dann mal das aktuelle Samba instalieren und gucken das es läuft.

gruss

[Clemens Beier]

Post by Thomas Kaiser
Ach ja, und warum überhaupt Linux? Die sauberste Lösung im Lowcost-
Bereich für gemischte Windows- und Mac-Zugriffe auf Dateiserver ist
entweder eine MacOS X Kiste (weil hat AppleFileServer und Samba 3.x an
Bord mit Patches bzgl. Interaktion zwischen beiden) oder eine Windows-
Schüssel mit ExtremeZ-IP 4/5 oder MacServer IP (ab Version 9).

"Mein" Admin stellt einen Linux-Server (AFAIK SUSE) zur Verfügung weil:

* keine zusätzlichen Lizenzkosten entstehen
* er ihn für Sicher hält (respektive das Gerät sich leichter als
"sicher" konfigurieren lässt als eine Windows-Kiste)
* auf dem Rechner eine OpenSource Rechnungslösung läuft die dazu noch
LaTeX-Rechnungen ausgibt.

Und das, obwohl 95% der angeschlossenen Rechner Mac-Clients sind.


ClemiSan

[Eberhard Lisse]

Was laeuft denn da? SQL-Ledger (bin sehr zufrieden damit)?

Ich habe eine Suse 10.0 Kiste im Einsatz, 4 Mini's zu Hause, je einen
Mini und eine XP Dose in der Praxis, die an einer Standleitung haengt,
und jeweils ein WLAN.

Das klappt super, mit einer Ausnahme, von XP unter Parallells kann ich
das XP Share nicht oeffnen, auf dem selben Mini gehts aber mit Apfel K
und dem selben Passwort :-)-O. Es gibt aber einen einfachen workaround,
sodass mich das nicht weiter zu Nachforschung veranlasst.

An sich Standardkonfigurationen, und etwas mit Workgroup und so
herumgespielt.

el

Post by Clemens Beier
* keine zusätzlichen Lizenzkosten entstehen
* er ihn für Sicher hält (respektive das Gerät sich leichter als
"sicher" konfigurieren lässt als eine Windows-Kiste)
* auf dem Rechner eine OpenSource Rechnungslösung läuft die dazu noch
LaTeX-Rechnungen ausgibt.
Und das, obwohl 95% der angeschlossenen Rechner Mac-Clients sind.
ClemiSan

[Juergen P. Meier]

Post by Horst Schulz
Ich hab in nem Büro nen alten PC zu nem File Server umfunktioniert
mittels Debian Woody. Darauf läuft halt Samba damit die restlichen
Windows Kisten darauf zugreifen können. Nun hat sich der Chef nen Mac
mit OS X geholt und will ebenfalls auf den Server zugreifen. Ich habs
versucht mittels smb und dem Server verbinden. Da hab ich dann die

Apfel-K, eingippen: "cifs://Servername/" wobei "servername" entweder
der Hostname ist, oder der SMB-Servername (also das, was Windos
Networking anzeigt).

Ansonsten einen Terminal oeffnen und mit smbclient testen:

smbclient -U username '\\server\share'
Passwort eintippen und mit "dir" schauen ob du dateien siehst.

Post by Horst Schulz
korrekte IP angegeben und auch den Mac User auf der Linuxkiste
eingerichtet. Da bekam ich dann die Meldung das Dateien nicht lesbar

Der der User auch auf die SMB-Shares zugreifen?

Post by Horst Schulz
waren und ich nun immernoch nicht auf die freigegebenen Verzeichnisse
zugreifen konnte. Nach mehreren erfolglosen Versuchen und kam ich damit
nicht wirklich voran. Dann probierte ich es mittels NFS nur da zickte
dann der portmap vom OS X rum und ich bekam ebenfalls keine Verbindung
zum File Server.

Portmapper auf dem Linux-Server laeuft? Was sagt "rpcinfo -p linuxrechner"

Aber in diesem Fall wuerde ich ueber SMB gehen, da damit am wenigstens
Probleme mit dem gemeinsamen Zugriff mit den Windows-Clients zu
erwarten sind.

Juergen

[Thomas Kaiser]

Post by Juergen P. Meier

Dann probierte ich es mittels NFS nur da zickte dann der portmap vom
OS X rum und ich bekam ebenfalls keine Verbindung zum File Server.

Portmapper auf dem Linux-Server laeuft? Was sagt "rpcinfo -p
linuxrechner"

Gar nicht weiter verfolgen, denn NFS ist in obiger Situation schlichtweg
nur eins von beidem: böse oder doof.

Weil... NFS kennt vor Version 4 (die ich in freier Wildbahn noch
nirgends angetroffen habe) keinerlei Einstellungen bzgl. Client-
seitigem Datei- und Verzeichnisnamen-Encoding.

D.h. jeder NFS-Client schmiert die Dateinamen so ins Dateisystems des
Servers, wie es ihm grad paßt. D.h. wenn MacOS X als Client am Start
ist, dann in der Variante "UTF-8 decomposed", die rein zufälligerweise
weit und breit kein anderes System auf diesem Planeten nutzt (außer
Netatalk in einer eher esoterischen volcharset-Einstellung).

Spätestens wenn man jetzt von anderen Plattformen drauf zugreift,
bekommt man Namenssalat, da andere Plattformen per NFS normalerweise mit
ISO 8859-1 oder UTF-8 *pre*composed daherrumpeln oder sich die passende
Server-Software darum kümmert, daß client-seitiges Encoding (bei Windows
bspw. UCS16) in passendes server-seitiges umgewandelt wird (bspw. UTF-8
*pre*composed, wenn Samba 3.x in Standardeinstellung)

Wenn man mal Dateinamensalat auf einem Server hat, dann hat man eine
Situation, aus der man nur mehrstufig und unter Zuhilfenahme von
reichlich blood, sweat and tears wieder herauskommt (wenn überhaupt).

Die Symptome sind nämlich in der Regel nicht nur, daß vom Client aus
betrachtet, Dateien im falschen Encoding nicht mehr geöffnet werden
können, sondern daß auch Verzeichnislistings ganz oder teilweise
abgeschnitten werden und normale Anwender dann meist zu ulkigen
Übersprungshandlungen neigen, wie schnell mal diese Ordner zu
verschieben, löschen, etc. (been there, seen that -- many times)

Gruss,

Thomas, das niemand wünschend, daher mal wieder auf diese NFS-immanente
Gefahrenquelle hinweisend...

[Horst Schulz]

Post by Thomas Kaiser
Gar nicht weiter verfolgen, denn NFS ist in obiger Situation schlichtweg
nur eins von beidem: böse oder doof.

Nene, das hab ich schon abgehakt :)

Gruss