NFS stolpert über Umlaute in Verzeichnisnamen

[uhansen]

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:

/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:

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!

 

[uhansen]

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?

 

[Marcel Bresink]

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.

LDAP und Kerberos habe ich nicht eingerichtet, da ich nur als einzelner Nutzer mit einem Rechner innerhalb meines WLANs darauf zugreife.

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).

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.

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.

Lösen ließ sich dies, indem ich auf dem MacBook die Mac-Datei "/etc/nfs.conf" bearbeitete.

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.

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.

Das hat garantiert nichts mit NFS zu tun.

 

[uhansen]

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.)

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.

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...

Das hat garantiert nichts mit NFS zu tun.

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.

Mit LDAP könnte man sich das Gebastel ersparen, auf dem Linux-Server einen festen Benutzer-Account voreinstellen zu müssen.

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...

 

[uhansen]

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:

 

[Marcel Bresink]

Einige Bemerkungen dazu:

HFS+ wird als Datenträger-Filesystem von NFS nicht unterstützt

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

Erweiterte Attribute (xattr) gehen beim Kopieren per NFS auf ext4 verloren.

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

Geht sonst noch was verloren?

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.

Programme lassen sich nicht von Netzwerkplatte starten

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:

Spotlight möglich.

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.

 

[uhansen]

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.

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.

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.

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.

 

[Marcel Bresink]

kann ich die Platte für die Spotlight-Indizierung des MacBooks freischalten.

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.

 

[uhansen]

Das reicht nicht, denn was sich dabei ergibt, ist kein "echtes" Spotlight,

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!

 

[uhansen]

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.

 

[tjp]

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.

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]

Ich stoße im Netz auf dieses Zitat von @Marcel Bresink von 2010 oder 2011:

Marcel Bresink:
Gewisse Programme können Dateien von NFS-Servern nicht öffnen, wenn diese Dateien nicht auch mit NFS angelegt wurden: Wenn Sie eine Macintosh-Datei auf einen NFS-Server ablegen, ohne dabei NFS zu benutzen (z.B. über AppleShare, Windows Sharing oder indem die Datei direkt auf dem Server erzeugt und auf die lokale Platte geschrieben wurde) und diese Datei Macintosh Resource Forks oder erweiterte Finder-Attribute verwendet, kann es später Probleme geben, diese Datei mit NFS zu öffnen. Jedes Dateiserverprotokoll verwendet unterschiedliche Methoden, Forks und Attribute zu verarbeiten. Diese Techniken sind miteinander nicht kompatibel, d.h. Sie können keine fork- oder attributbehaftete Datei mit dem einem Protokoll schreiben und diese dann mit einem anderen Protokoll lesen.

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!