bbruecker
Anmeldungsdatum: 8. Juni 2006
Beiträge: 98
|
Hi, für den Dateiaustausch von mehreren Benutzern möchte ich dass die Gruppe users automatisch für alle Dateien Ordner meiner NFS-Freigabe erhält. Mithilfe der Setgid (g+rws) erhalten jetzt neue Unterordner und Dateien die Gruppe users. Das reicht aber nicht für Schreibrechte. So wie ich es verstehe, werden bei NFS (anders als bei Samba und Netatalk) die Ordner- und Dateirechte ausschließlich Client-seitig gesteuert. Daher habe ich am Client-Benutzer die umask auf 0002 in der .profils-Datei eingestellt. Jetzt werden zwar neu angelegte Dateien und Ordner mit Schreibrechten für die Gruppe angelegt, leider funktioniert das aber nicht beim Kopieren vom Client auf die Server-Freigabe. Das betrifft sowohl Kopieren per cp auf der Shell, als auch Kopieren über Nautilus. Die Dateien werden zwar auf dem Server der Gruppe users zugeordnet, erhalten aber keine Schreibrechte – außer die Quelldatei hatte schon Schreibrechte. Offenbar werden beim Kopieren auch die Rechte 1:1 kopiert, was für viele Anwendungsfälle ja gewollt sein kann, aber den Benutzeraustausch nicht gerade günstig ist. Weiß jemand, wie ich sicherstellen kann, dass per NFS erstellte, kopierte und verschobene Dateien und Ordner Schreibrechte für die Gruppe erhalten? Danke!
|
Max-Ulrich_Farber
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7964
|
So wie ich es verstehe, werden bei NFS (anders als bei Samba und Netatalk) die Ordner- und Dateirechte ausschließlich Client-seitig gesteuert
Ich verstehe nicht, was Du damit meinst. Die Rechte werden bei NFS 1:1 zwischen Server und Client übernommen. Voraussetzung ist allerdings, dass die UID und GID auf Server und Client übereinstimmen (!). Sonst muss man die UID und GID mappen, und das macht es nicht einfacher. Offenbar werden beim Kopieren auch die Rechte 1:1 kopiert
Ja. Bei Samba ist es nebenbei genau so, wenn man mit den cifs-UNIX-Extensions arbeitet. Gruß – Max-Ulrich
|
bbruecker
(Themenstarter)
Anmeldungsdatum: 8. Juni 2006
Beiträge: 98
|
Danke Max-Ulrich_Farber für die Antwort! Ich dachte schon, dass es keiner beantworten kann. Also wie ich es befürchtet habe: Es gibt unter NFS keine Option um serverseitig Schreibrechte für die Gruppe einzustellen. Für manche mag die Übertragung der Benutzerrechte ja nützlich sein, für meinen Anwendungsfall passt es leider nicht. Da muss jeder immer von Hand die Rechte checken und notfalls erteilen. Das wird gerne vergessen. Jetzt fallen mir nur noch Cron-Jobs ein. Aber geht das nicht eleganter?
|
Hans9876543210
Anmeldungsdatum: 2. Januar 2011
Beiträge: 3741
|
Ich hab dein Anliegen zwar nicht verstanden, aber wären nicht die Optionen all_squash,anonuid=x,anongid=y das was du suchst? Sprich, egal welche Benutzer die Dateien in deinem Share anlegen, alle Dateien werden auf den Benutzer x samt Gruppe y gemappt.
|
bbruecker
(Themenstarter)
Anmeldungsdatum: 8. Juni 2006
Beiträge: 98
|
Hallo Hans9876543210, ich versuch mein Ziel anders auszudrücken: Ich möchte, dass alle Dateien einer Freigabe Schreibrechte für die Gruppe haben, damit sichergestellt ist, dass unterscheidliche Benutzer mit den Dateien und Ordnern arbeiten können. Ich beschreibe mal meinen Erkenntnisweg detaillierter. Für mein Projekt habe ich unterschiedliche Leute mit Linux- und MacOS-Clients. Bei MacOS habe ich leider ein paar Probleme mit NFS. U.A. ist die Performance mit NFS schlechter, als mit Netatalk. Aus mir unerfindlichen Gründen legt NFS von einem MacOS-Client immer wieder Denkpausen ein, was bei Linux-NFS-Clients nicht der Fall ist. Es gibt aber auch Probleme mit Umlauten im Dateinamen. Außerdem ist der Zugriff am MacOS-Client auf AFP für die Benutzer sehr einfach. Die Performance mit Samba ist leider richtig schlecht. Hier kriege ich ohne Tuning 55 MB/S und mit Tuning auch nur 65 MB/S hin. Da ich keine Windows-Clients habe, benötige ich Samba zum Glück nicht (vielleicht ist das aber eine Client-Frage). AFP am MacOS-Client und NFS am Linux-Client liefern glatt das Doppelte von Samba. In einem ähnlichen Bereich wie Samba bewegt sich unglücklicherweise auch AFP am Linux-Client. Da Performance wichtig ist (es geht um Filmmaterial), möchte ich den Linux-Clients NFS und den MacOS-Clients AFP anbieten. Für Netatalk brauche ich nur einen Linux-Benutzerkonto auf dem Server und die Benutzer können sich autorisieren. Alle Benutzer sind Mitglieder der Gruppe "users". Über das Setgit-Bit am Freigabe-Ordner werden alle Dateien und Ordner mit Gruppenzugehörigkeit "users" erstellt – auch wenn sie dorthin kopiert werden. Bei Netatalk kann ich über dperm-Option auch Schreibrechte für die Gruppe mitgeben. Das funktioniert auch, wenn die Quell-Dateien und -Ordner nur Leserechte für die Gruppe hatten. Wie ich es drehe und wende, sehe ich nur folgende Möglichkeiten:
Über NFS sicherstellen, dass alle Dateien und Ordner mit Schreibrechten für die Gruppe erstellt und kopiert werden. Geht wohl nicht? Oder? Netatalk dazu bringen auch User zu mappen. Auch hier finde ich nichts. Oder habe ich etwas übersehen? Cronjobs zum Sicherstellen der Schreibrechten für die Gruppe (eigentlich nicht schön....).
|
Max-Ulrich_Farber
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7964
|
Danke für die ausführliche Beschreibung. Doch leider erkenne ich das Problem immer noch nicht. Geht denn folgendes nicht?
Auf Server und Clients umask 002 einstellen, damit die Gruppe schreiben darf (ist in Ubuntu eh Standard). Alle schreibberechtigten Benutzer auf Server und Clients einer Gruppe xyz zuordnen. Diese Gruppe muss auf Server und Clients die gleiche GID haben. Bei den betroffenen freigegebenen Ordnern auf dem Server xyz mittels sudo chgrp -R xyz <Ordner> als Gruppe eintragen und diese gleich mit dem SGID-Bit vererbbar machen. Dann dürfen alle Mitgliederder Gruppe xyz auch in neu erstellten Unterordnern und Dateien schreiben.
Ich habe dieses Vorgehen zwar noch nicht mit NFS ausprobiert, doch ich sehe nicht, warum es nicht gehen sollte. Für mein Projekt habe ich unterschiedliche Leute mit Linux- und MacOS-Clients. Bei MacOS habe ich leider ein paar Probleme mit NFS.
Ich habe mit MacOS leider keinerlei Erfahrung. Doch allgemein gilt, dass NFS bei UNIX/Linux-Clients eine runde Sache ist, dass es aber Probleme mit den Dateirechten geben kann, sobald andere Betriebssysteme mit im Spiel sind. In solchen Fällen ist man meist mit Samba besser bedient, wo sich ähnliche Probleme recht einfach und ganz differenziert mit den Optionen inherit permissions , inherit owner und inherit acls systemübergreifend lösen lassen. Gruß – Max-Ulrich
|
bbruecker
(Themenstarter)
Anmeldungsdatum: 8. Juni 2006
Beiträge: 98
|
Hallo Max-Ulrich, danke für Deine Geduld. Wie gesagt ist Samba leider zu lahm (ich mach vielleicht mal einen anderen Thread dazu auf). So wie Du die Server-Konfiguration beschrieben hast, bin ich auch vorgegangen. Die Sache hat leider ein paar Haken:
Beim Erstellen funktioniert es, aber nicht beim Kopieren. Also: Wenn ich als eine Datei kopiere, die nur Leserechte für die Gruppe habe, landen Sie bei mir auch nur mit Leserechten auf dem NFS-Server. Wenn auch das bei Dir anders ist, fände ich das spannend. Nach meiner Beobachtung ist leider umask von Distribution zu Distribution sehr unterschiedlich vorkonfiguriert. Lieder komme ich nicht an alle Clients ran, um die umask zu setzen. Darum wäre mir eine serverseitige Konfiguration wie bei Netatalk lieber.
Wenn es bei NFS mit den Gruppenschreibrechten beim Kopieren nicht geht, geht es halt nicht. Die Frage ist dann, welche Alternativen oder Work-a-rounds es gibt.
|
Max-Ulrich_Farber
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7964
|
Beim Erstellen funktioniert es, aber nicht beim Kopieren. Also: Wenn ich als eine Datei kopiere, die nur Leserechte für die Gruppe habe, landen Sie bei mir auch nur mit Leserechten auf dem NFS-Server.
Das ist normal und somit bei mir auch nicht anders. Und das wäre bei Samba mit den UNIX-Extensiuns auch nicht anders. Wenn auf dem Client mittels Dateimanager kopiert wird, sehe ich keinen Ausweg. Wenn hingegen im Terminal mit dem Befehl cp kopiert wird, dann könnte vielleicht die Option --no-preserve=mode funktionieren. Ausprobiert habe ich das allerdings nicht.
Wie gesagt ist Samba leider zu lahm
Ist bei Dir Samba wirklich soo lahm? Denn mit Samba wärest Du recht einfach aus dem Schneider. Einfach die UNIX-Extensions auf dem Server mit unix extensiuns = no oder auf dem Client mit nounix deaktivieren, oder für den Zugriff auf dem Client einfach das GVFS verwenden.
|
bbruecker
(Themenstarter)
Anmeldungsdatum: 8. Juni 2006
Beiträge: 98
|
Hallo Max-Ulrich_Farber, nochmals Danke, in Bezug auf NFS weiß ich jetzt zumindest, dass ich nichts übersehen habe. Bei dem Projekt, wo es um Filmschnitt von eher 10-100-GB-großen Dateien geht, ist die Performance wichtig. Ich habe darum noch mal mit dd für eine 2,5 GB Datei paar mal schreibend auf den Server durchgemessen. Ich habe ein Gigabit-Netzwerk verwendet, an dem nur der Server und mein Testclient hängen. Für die Tests habe ich eine SSD im Server genommen. Linux- und Mac-Client verwenden die selbe Hardware, da der Mac ein Hackintosh auf dem selben Computer ist: SAMBA: Ich habe mal Deine Optionen sowohl server- als auch clientseitig gesetzt. Mit Samba lande ich bei beschiedenen 45-50 MB/S, egal ob Mac- oder Linux-Client. Das war auch vorher so. Die Werte sind übrigens für Mac- und Linux-Clients fast gleich; Linux ist eher ein 2-3 MB/S schneller. Ich habe folgende Tunig-Variante gefunden (socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=65536 SO_SNDBUF=65536, die am Linux-Client 60 MB/S erbrachte, aber leider bleibt Mac lahm (siehe https://calomel.org/samba_optimize.htm). Mein Verdacht ist also, dass die Geschwindigkeit auch Client-abhängig ist. Da ich kein Windows habe, kann ich das nicht durchtesten. Allerdings ist Windows für mich nicht interessant, da ich nur Mac- und Linux-Clients zu versorgen habe. Netatalk/AFP: AFP vom Mac-Client ist mit immer etwas mehr als 102 MB/S der Spitzenreiter. Leider nicht unter Linux, hier lande ich höchstens bei 70 MB/S. NFS: Wie zu erwarten ist NFS am Linux-Client mit 98 MB/S am schnellsten. Aber 100 MB/S wie bei AFP vom Mac-Client habe ich nie gesehen.
Ich stelle mir jetzt folgende Fragen.
|