NFS stolpert über Umlaute in Verzeichnisnamen

Dieses Thema im Forum "Netzwerk" wurde erstellt von uhansen, 05.05.18.

  1. uhansen

    uhansen Friedberger Bohnapfel

    Dabei seit:
    29.09.11
    Beiträge:
    526
    Ich baue gerade meinen kleinen intel NUC NUC5I5RYH Server mit Ubuntu 16.04 zum NFS Fileserver aus, da der Platz auf der 1 TB SSD in meinem MacBook Pro 13" (Early 2011) mit OSX 10.11.6 (El Capitan) ausgeht und ein Nachfolgemodell aus Kostengründen eher eine kleinere SSD haben wird.

    Auf dem Ubuntu-System sieht "/etc/exports" so aus:
    Code:
    /export         192.168.1.0/24(rw,fsid=0,async,insecure,all_squash,no_subtree_check,anonuid=1000,anongid=1000)
    /export/nfs     192.168.1.0/24(rw,nohide,async,insecure,all_squash,no_subtree_check,anonuid=1000,anongid=1000)

    /export und /export/nfs haben die Zugriffsrechte 777. Alle darunter liegenden Dateien und Verzeichnisse gehören meinem Ubuntu-Benutzer (UID/GID 1000) und sind 644 bzw. 755.

    LDAP und Kerberos habe ich nicht eingerichtet, da ich nur als einzelner Nutzer mit einem Rechner innerhalb meines WLANs darauf zugreife. Brauche ich eine Datei von unterwegs, mache ich das über SFTP.

    Für das automatische Einbinden auf dem MacBook kommt der NFS-Manager von @Marcel Bresink zum Einsatz.

    Hier sind unter "Autoaktivierungen" die Optionen "nosuid, bg, resvport, soft, nfc" gewählt sowie unter "Konfiguration - Automounter" die Optionen "nodev, nosuid, rdirplus, locallocks, nolocks, nfc". (Siehe Bilder.)

    Vor allem "locallocks" und "nolocks" erwiesen sich als bitter notwendig, da das MacBook ohne diese Optionen immer mal wieder stockte, den Beachball zeigte und sich einmal sogar weigerte, herunterzufahren.

    Obwohl in beiden Optionsfeldern auch "nfc" angewählt ist, konnte ich mit dem Finder keine Dateien von der gemounteten NFS-Freigabe kopieren, wenn sie in einem Verzeichnis mit Umlaut "ü" lagen. OS X meldete dann:

    "Es ist ein unbekannter Fehler aufgetreten (Fehler -43)".

    Lösen ließ sich dies, indem ich auf dem MacBook die Mac-Datei "/etc/nfs.conf" bearbeitete. Dort habe ich die Zeile eingefügt:
    Code:
    nfs.client.mount.options = nfc

    Das behob die Umlautprobleme. Seitdem läuft es eigentlich sehr stabil und schnell. Vielleicht kann ich den lokalen Platzbedarf so ja doch auf unter 500 GB drücken - und mich dann nach einem aktuelleren MacBook Pro umsehen ;)

    Sieht jemand noch Fehler in der Konfiguration? Vielen Dank!

    [​IMG]
    [​IMG]
     
    #1 uhansen, 05.05.18
    Zuletzt bearbeitet: 05.05.18
  2. uhansen

    uhansen Friedberger Bohnapfel

    Dabei seit:
    29.09.11
    Beiträge:
    526
    Merkwürdige Probleme: eine PDF-Datei die eigentlich 175 kB groß sein sollte, hat auf der NFS-Freigabe auf einmal 45 MB und lässt sich nicht mehr öffnen. Ein Verzeichnis liegt auf einmal an einen falschen Ort.

    Woran das liegt, weiß ich noch nicht. Durch den schnellen Zugriff arbeitet man mit NFS-Verzeichnissen, als wären es lokale. Möglicherweise habe ich irgendwas zu schnell gemacht. Oder an den Optionen ist irgendwas faul. Ich spiele jetzt erst mal alle Daten von einem CCC Backup zurück.

    Was nützt es einem, seine Daten auf einem Server zu haben, wenn man nicht sicher sein kann, dass sie dort auch korrekt gespeichert werden?
     
    #2 uhansen, 06.05.18
    Zuletzt bearbeitet: 06.05.18
  3. Marcel Bresink

    Marcel Bresink Clairgeau

    Dabei seit:
    28.05.04
    Beiträge:
    3.722
    NFS stolpert grundsätzlich nicht über Umlaute in Verzeichnisnamen, da das Protokoll beliebige Codierungen der Dateinamen zulässt.

    Aber genau das kann zu einem Problem im macOS-Finder führen, der Objekte grundsätzlich nicht anzeigt und alle Operationen für solche Objekte mit "Fehler -43" ablehnt, falls die Dateien einen Namen haben, der nicht der macOS-Regel entspricht, Unicode mit der Codierung UTF-8 und der Normalisierung "Typ D" zu verwenden.

    Windows-Systeme und manche Unix-Systeme verwenden Unicode UTF-8 mit der Normalisierung "Typ C". Wenn also solch ein fremdes Betriebssystem eine Datei mit speziellen Zeichen auf der NFS-Freigabe ablegt, kann es sein, dass der Finder diese ablehnt. Ist das nicht gewünscht, muss man die NFC-Option einschalten, damit NFS jeden Dateinamen während der Verarbeitung prüft und gegebenenfalls so konvertiert, dass der Finder damit zurechtkommt.

    Kerberos ist in der Regel nur für NFSv4 nötig.

    Mit LDAP könnte man sich das Gebastel ersparen, auf dem Linux-Server einen festen Benutzer-Account voreinstellen zu müssen. Ohne LDAP ist es eben technisch nicht ein einzelner Nutzer, da die Benutzer-Accounts des Linux-Systems nicht mit denen des Mac synchronisiert sind. Man hat also zwei verschiedene Sätze von Benutzer-Accounts (die sich möglicherweise sogar widersprechen und damit Sicherheitslücken auslösen können).

    Das Einschalten der Option reicht aus. Wird dies jedoch im laufenden Betrieb gemacht, liegt es im Ermessen von macOS, das erst bei nächsten expliziten Mount-Vorgang wirksam werden zu lassen, bzw. die Operationen im Finder erst dann zu erlauben, wenn der Datei-Cache neu gefüllt wurde. Ein Neustart des Mac hätte also wahrscheinlich gereicht.

    Das ist zu umständlich. Mit NFS Manager würde es reichen, die Option in den Einstellungen des NFS-Klienten (nicht in den Einstellungen des macOS-Automounters) anzukreuzen. Aber wie gesagt lag es wahrscheinlich nur an einer Verzögerung in macOS.

    Das hat garantiert nichts mit NFS zu tun.
     
  4. uhansen

    uhansen Friedberger Bohnapfel

    Dabei seit:
    29.09.11
    Beiträge:
    526
    Vielen Dank, @Marcel Bresink, für die sehr gute, ausführliche Erklärung! (Leider ist mir der Thread-Titel missraten, da er NFS die Verantwortung zuweist.)

    In der Tat hatte ich keinen Reboot gemacht. Mist. ("Did you try turning it off and on again?") Das habe ich inzwischen nachgeholt. Vorerst lasse ich mal /etc/nfs.conf so, oder, es scheint ja zu laufen...

    Ja, ich war etwas schockiert, als ich sah, dass es die obigen Merkwürdigkeiten mit den Daten gibt. Danke für die Einschätzung! Inzwischen liegt mein Verdacht bei "Paragon ExtFS for Mac" - ich hatte nämlich mit dessen Hilfe 500GB an Daten von meinem Mac auf eine per USB angeschlossene ext4-Festplatte übertragen, aus Zeitgründen. Dann habe ich die ext4-Platte im Ubuntu-Server eingehängt und mit NFS exportiert. Möglicherweise hatte sich ja dieser Paragon-Treiber verschluckt.

    Jetzt starte ich komplett neu, indem ich die 500 GB von einer Backup-Platte nehme, das heißt, die ist als HFS-Platte read-only in Ubuntu eingehängt und ihre Daten werden dort auf eine mit mkfs.ext4 frisch formatierte ext4-Platte kopiert, die wird dann per exports mit NFS freigegeben. Dann teste ich das mal eine Weile. Zum Glück habe ich mehrere Backups. :)

    Danke für den Hinweis! Ja, das wäre schon sehr attraktiv, exakt den gleichen Nutzer mit gleicher UID,GID auf beiden Systemen zu haben, besser als per "all_squash,anonuid=1000,anongid=1000" alle Zugriffe des Clients auf den Server-Benutzer umzubiegen. Die Lernkurve für die Einrichtung eines OpenLDAP-Servers unter Ubuntu scheint nur leider recht steil zu sein. Muss mal schauen, ob ich das packe...
     
    #4 uhansen, 06.05.18
    Zuletzt bearbeitet: 06.05.18
    Aaron46 gefällt das.
  5. uhansen

    uhansen Friedberger Bohnapfel

    Dabei seit:
    29.09.11
    Beiträge:
    526
    Ich habe jetzt zwei Lösungen am Laufen. Einmal die Beschriebene über NFS. Und als zweites eine externe Festplatte an einer AirPort Extreme.

    Ich bin noch unentschlossen, welche Lösung ich verwende, hier meine Pro und Contras. Vielleicht gibt es ja hier noch Meinungen... Danke!

    NFS

    Externe Festplatte wird an Ubunu-Server 16.04 angeschlossen und per NFS freigegeben.


    Vorteile
    • Schnell. Server hat USB3, also schnelle Anbindung der Freigabe-Festplatte.
    • Zugriff von Server auf gemountete Platte möglich und damit auch von außen per SSH/SFTP, bei entsprechend angelegtem User mit UID 501.
    • Sicherung per rsync auf zusätzliche Platte möglich.

    Nachteile NFS
    • HFS+ wird als Datenträger-Filesystem von NFS nicht unterstützt, die Platte lässt sich also nicht so einfach wieder an den Mac stöpseln.
    • Erweiterte Attribute (xattr) gehen beim Kopieren per NFS auf ext4 verloren. (Ist das relevant? Geht sonst noch was verloren?)
    • Kein Spotlight möglich.
    • Keine Sicherung mit TimeMachine möglich.
    • Programme lassen sich nicht von Netzwerkplatte starten

    AFP

    Externe Festplatte hängt an Airport Extreme

    Vorteile
    • Sehr einfache Konfiguration.
    • Filesystem bleibt HFS+.
    • Spotlight möglich.
    • Sicherung per TimeMachine ginge, erfordert aber gelegentliches Anstöpseln der Platte an den Mac.
    • Programme lassen sich von Netzwerkplatte starten
    • Zugriff von Ubuntu-Server auf per cifs/smb gemounte Platte möglich, und damit auch von außen (SSH/SFTP), (bei entsprechend angelegtem User mit UID 501)
    • Sicherung per rsync von Server aus auf zusätzliche Platte möglich.
    Nachteile AFP
    • Sehr viel langsamer. Airport Extreme hat nur USB2.
    • Die AirPort Extremes und AFP sind von Apple abgekündigt.
    Geschwindigkeit

    Die Geschwindigkeitsunterschiede sind groß, wahrscheinlich vor allem durch den lahmen USB2-Port der AirPort Extreme.

    Allerdings fällt das über WLAN nicht mehr so stark ins Gewicht. Siehe Bilder:

    [​IMG]
    [​IMG]
     
    #5 uhansen, 09.05.18
    Zuletzt bearbeitet: 09.05.18
  6. Marcel Bresink

    Marcel Bresink Clairgeau

    Dabei seit:
    28.05.04
    Beiträge:
    3.722
    Einige Bemerkungen dazu:

    Im Prinzip ginge das schon, aber die derzeitigen HFS+-Treiber für Linux lassen das nicht zu.

    Das stimmt nicht, da macOS die Attribute in diesem Fall clientseitig über AppleDouble-Dateien emuliert.

    Falls nicht NFSv4 verwendet wird, gehen Zugriffssteuerungslistenberechtigungen verloren. Da in der oben beschriebenen Konfiguration aber sowieso nicht mit netzweiten Benutzer-Accounts gearbeitet wird, spielt das keine Rolle.

    Warum sollte das nicht gehen? Das funktioniert einwandfrei.
    Nachtrag: Aus der obigen Beschreibung wird nicht ganz klar, wie die Rechte der einzelnen Dateien auf der Freigabe angepasst wurden. Aber wenn Du wirklich die Rechte für sämtliche Dateien auf 0644 gesetzt hast, hast Du Dir natürlich die Berechtigung entzogen, Programme starten zu dürfen.

    Bei AFP:
    Das stimmt nicht, denn dazu müsste auf der Airport Extreme der Dienst "Spotlight Server" laufen. Die Airport Extreme ist dazu nicht leistungsfähig genug, deshalb bietet Apple diesen Dienst nicht an.
     
    #6 Marcel Bresink, 09.05.18
    Zuletzt bearbeitet: 09.05.18
  7. uhansen

    uhansen Friedberger Bohnapfel

    Dabei seit:
    29.09.11
    Beiträge:
    526
    OK. Das Problem saß offenbar vor dem Bildschirm und guckte dumm. Ich habe das inzwischen neu gemacht - und natürlich nicht mehr überall 755 und 644 drüber gebügelt. Jetzt ist das Ganze eine 1:1 Kopie der Dateien, wie sie auf dem Mac lagen. Ich habe auf dem Linux-Server einen eigenen Benutzer "appleirgendwas" angelegt mit UID 501 und GID 80, der hat auch einen SSH Zugang mit Schlüssel. LDAP spare ich mir noch auf. Vom Mac aus Programme zu starten, die auf der NFS-Freigabe liegen, klappt jetzt.

    Hmm. Meine Platte ist an die Airport Extreme angeschlossen. Sie hat den Laufwerksnamen "CrucialMX200SSD-1" (don't ask) und wird nun entsprechend automatisch auf meinem MacBook von MacOS auf "/Volumes/CrucialMX200SSD-1" gemounted.

    Mit

    mdutil /Volumes/CrucialMX200SSD-1 -i on

    kann ich die Platte für die Spotlight-Indizierung des MacBooks freischalten. Das habe ich eben gemacht und in der Aktivitätsanzeige ist "mds" fröhlich am Laufen.

    [​IMG]
     
    #7 uhansen, 09.05.18
    Zuletzt bearbeitet: 09.05.18
  8. Marcel Bresink

    Marcel Bresink Clairgeau

    Dabei seit:
    28.05.04
    Beiträge:
    3.722
    Das reicht nicht, denn was sich dabei ergibt, ist kein "echtes" Spotlight, sondern nur ein Einmalindex des jetzigen Volume-Inhalts.

    Es ist nicht gewährleistet, dass korrekte Suchergebnisse geliefert werden, wenn nach Erstellen des Index Dateien neu hinzukommen, gelöscht werden, oder sich Inhalte der Dateien ändern. Dazu wäre eine serverseitige (!) Live-Verfolgung aller Dateiänderungen und ein entsprechendes Auffrischen der Indexdatenbanken nötig.
     
  9. uhansen

    uhansen Friedberger Bohnapfel

    Dabei seit:
    29.09.11
    Beiträge:
    526
    Vielen Dank für die Erklärung. Es scheint, die vermeintlichen Vorteile der AirportExtreme schwinden dahin. Letztlich bleibt es eine Frage des Vertrauens: Vertraue ich die ganzen Daten, die sich über einen Zeitraum von zwanzig Jahren angesammelt haben, einem Linux-Server, ext4 und NFS an oder einer lahmen, aber lange Jahre sehr zuverlässigen Airport Extreme, HFS+ und AFP/SMB.

    Noch habe ich beides am Laufen und beobachte, wie das klappt. Aber irgendwann muss ich mich entscheiden, weil das ja auch mein Ablagesystem für Dokumente ist und ich nicht zwei Datengräber gleichzeitig pflegen will.

    Eine Art Stresstest für Netzwerkserver wäre vielleicht noch interessant.

    @Marcel Bresink: Der NFS-Manager macht übrigens einen super Job und bewahrt einen davor, in die Tiefen des Systems zu tauchen und was falsch zu machen. Reboot, Schlafmodus, Hibernate des Mac oder Schlafmodus der Netzwerk-Festplatte, die NFS-Freigabe ist immer da. Danke!
     
  10. uhansen

    uhansen Friedberger Bohnapfel

    Dabei seit:
    29.09.11
    Beiträge:
    526
    Nachtrag zum Vergleich NFS mit AFP/SMB

    Der Vollständigkeit halber hier noch ein Test der AFP/SMB-Verbindung mit einer AirPort TimeCapsule und ihrer INTERNEN Platte - das heißt ohne den Flaschenhals der USB2-Anbindung. Man sieht sehr schön, dass die Verbindung zu den AirPort-Geräten auch bei interner Platte erheblich langsamer ist als die zu dem Ubuntu-Server mit NFS: Waren bei letzterem 108 MB/s Schreiben und 70,9 MB/s Lesen möglich (siehe oben), sind es hier gerade mal 27,7 MB/s Schreiben und 52,6 MB/s Lesen.
    [​IMG]
     
  11. tjp

    tjp Clairgeau

    Dabei seit:
    07.07.04
    Beiträge:
    3.693
    Für Linux gibt es passende Hardware, so dass dort die Daten gut aufgehoben sind. Ext4 ist grundsolides Dateisystem, wird aber für große Dateisysteme nicht empfohlen. RedHat empfiehlt es nur für maximal 16TiB, für bis zu 500TiB empfiehlt RedHat XFS. Bei anderen Anbieter variieren diese Zahlen etwas. Ich glaube nicht, dass der typische Mac-Nutzer in Verlegenheit kommt mehr als ½ PiB an Dateien verwalten zu müssen, aber auch dafür gibt es Lösungen.

    Ubuntu bringt eine einfache Backup Lösung mit, so dass einfach auf ein andere USB-Laufwerk ausgelagert werden können. Wenn man gewillt ist sich mit dem Thema Bacula auseinandersetzen zu setzen, dann gibt es eine hochprofesionelle FOSS-Lösung fürs Backup die zentral alle Windows, macOS und *I*X Clients verwalten kann. Bacula hat nur einen gewichtigen Nachteil, es ist extrem mächtig und entsprechend komplex zu verstehen.
     
    uhansen gefällt das.
  12. uhansen

    uhansen Friedberger Bohnapfel

    Dabei seit:
    29.09.11
    Beiträge:
    526
    Ich stoße im Netz auf dieses Zitat von @Marcel Bresink von 2010 oder 2011:

    Ist das noch aktuell? Ich hatte eigentlich vor, die NFS-Freigabe nur innerhalb des WLANs zuhause zu nutzen. Wenn ich von unterwegs eine Datei brauche, wollte ich von außen per SFTP auf den Heimserver zugreifen und die Datei damit von der angeschlossenen Festplatte holen, bearbeiten und zurücklegen. Dafür habe ich mir einen User angelegt, der die UID meines Mac-Benutzers hat (501). Kann es dann (s.o.) Probleme geben?

    Ich könnte vermutlich die NFS-Freigabe auch auf dem Server selbst per NFS mounten und darauf zugreifen, wenn ich mich von außen per SFTP verbinde. Dann sollten alle Zugriffe per NFS stattfinden... Habe das aber noch nicht ausprobiert.

    Vielen Dank!