NFS-Freigabe von Linux mit akzentuierten und Nicht-ASCII-Zeichen - Dateien funktionieren im Terminal, aber nicht in Programmen

Ich habe meine Musik- und Filmsammlung auf einem Linux-Server und die Dateinamen enthalten Nicht-ASCII-Zeichen. Das ist an sich kein Problem, da der Musikserver auch auf dem gleichen Server läuft und alles in Ordnung ist.

Die Gebietsschemaeinstellungen des Servers sind:

root@lms:~# locale
LANG=C
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=en_US.UTF-8

und die Clients (macOS Sierra) sind:

09:15:38 ~$ locale
LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL="en_US.UTF-8"

Aber ich verwende OS X / macOS auf meinem Desktop-Computer und möchte die Dateien (Taggen, Sortieren, ...) mit OS X-Programmen verwalten. Ich habe eine NFS-Freigabe auf dem Linux-Server wie folgt erstellt:

/exports/Music          192.168.1.201(rw,async,crossmnt,no_subtree_check,insecure,all_squash,anongid=1002,anonuid=501) 192.168.1.0/255.255.255.0(ro,async,crossmnt,no_subtree_check,insecure,all_squash,anonuid=501,anongid=1002)

und auf dem Apple montiert:

lms:/exports/Music on /Volumes/Music (nfs, nodev, nosuid, mounted by rainerkrug)

Mein Problem ist, dass ich die Dateien mit Nicht-ASCII-Zeichen mit dem Finder nicht kopieren kann (Finder sagt mir

Der Vorgang kann nicht abgeschlossen werden, da mindestens ein erforderliches Element nicht gefunden werden kann. (Fehlercode -43)

Wobei Fehlercode -43 "Datei nicht gefunden" bedeutet.

Aber ich kann die Datei vom Terminal kopieren.

Dies spiegelt sich auch darin wider, dass ich die Datei auf dem externen Volume nicht mit der rechten Maustaste öffnen kann, aber ich kann die lokale, die ich kopiert habe, mit dem Terminal öffnen, oder dass andere Programme (z. B. Metadatics zum Bearbeiten von Tags) nicht sehen können oder mit den Dateien arbeiten.

Das Ganze klingt für mich ziemlich seltsam, da macOS und Linux mit den Nicht-ASCII-Zeichen (insbesondere Akzentzeichen) arbeiten können, aber macOS hat Probleme beim Zugriff auf die Freigabe?

Kann ich irgendetwas tun, außer die Dateinamen in ASCII-Zeichen zu ändern? Gibt es Mount-Optionen, die ich einstellen sollte?

Ich sollte erwähnen, dass dieses Problem in Sierra nicht neu ist - es gab es auch unter ElCapitan.

Antworten (1)

OK - ich habe hier https://discussions.apple.com/message/21199204#message21199204 die Antwort gefunden. Ich zitiere:

Nach langem Lesen habe ich gelernt, dass es mehrere Möglichkeiten gibt, dasselbe Unicode-Zeichen zu konstruieren, und daher gibt es für einen effizienten Vergleich ein Konzept namens Normalisierung ( http://www.unicode.org/reports/tr15/ ). Nach der Normalisierung mit demselben Algorithmus ist die Darstellung jedes Zeichens konsistent.

Leider gibt es mehrere Normalisierungsalgorithmen und keinen Konsens darüber, welche verwendet werden sollen. Apple verwendet NFD, während die meisten anderen Betriebssysteme NFC verwenden. NFS gibt keine Normalisierungsmethode an, daher kann OSX nicht ohne Weiteres konvertieren.

Alles, was ich tun musste, um dies zu beheben, war, NFS mitzuteilen, dass meine NFS-Freigaben NFC verwenden. Dann erschienen alle Dateien mit den ungeraden Zeichen und wurden gut gelesen.

Ich tat dies, indem ich diese Zeile zu /etc/nfs.conf auf dem Mac hinzufügte.

nfs.client.mount.options = intr,locallocks,nfc

Funktioniert perfekt.


Ergänzung: Die Optionen beziehen intr,locallockssich nicht auf die Zeichenkodierung, daher sollte die Lösung workinf=g ohne diese sein, dh

nfs.client.mount.options = nfc

Obwohl ich dies nicht ausprobiert habe, da diese beiden Optionen in meinem Anwendungsszenario sinnvoll sind.

Danke für die Klarstellung - es hat nichts mit Zeichenkodierung zu tun - also sollte es ohne funktionieren. Aber diese Optionen machen für mich in meinem Anwendungsszenario Sinn - möglicherweise sogarnolock