Uso compartido de NFS desde Linux con caracteres acentuados y no ascii: los archivos funcionan en la terminal pero no en los programas

Tengo mi colección de música y películas en un servidor Linux y los nombres de los archivos contienen caracteres que no son ascii. Esto en sí mismo no es un problema ya que el servidor de música también se ejecuta en el mismo servidor y todo está bien.

La configuración regional del servidor es:

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

y los clientes (macOS Sierra) son:

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"

Pero estoy usando OS X / macOS en mi computadora de escritorio y me gustaría administrar los archivos (etiquetado, clasificación, ...) usando programas OS X. He creado un recurso compartido NFS en el servidor Linux de la siguiente manera:

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

y montado en la manzana:

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

Mi problema es que no puedo copiar los archivos con caracteres que no sean ascii usando Finder (finder me dice

No se puede completar la operación porque no se pueden encontrar uno o más elementos necesarios. (Código de error -43)

Donde el código de error -43 significa y "Archivo no encontrado".

Pero puedo copiar el archivo desde la terminal.

Esto también se refleja en que no puedo abrir el archivo en el volumen externo haciendo clic con el botón derecho del mouse, pero puedo abrir el local que copié usando la terminal, o que otros programas (por ejemplo, Metadatics para editar etiquetas) no pueden ver o trabajar con los archivos.

Todo esto me suena bastante extraño, ya que macOS y Linux pueden funcionar con caracteres que no son ascii (caracteres acentuados en particular), pero macOS tiene problemas al acceder al recurso compartido.

¿Hay algo que pueda hacer excepto cambiar los nombres de los archivos a caracteres ascii? ¿Hay opciones de montaje que debería configurar?

Debo mencionar que este problema no es nuevo en Sierra, también estaba allí en ElCapitan.

Respuestas (1)

OK - Encontré aquí https://discussions.apple.com/message/21199204#message21199204 la respuesta. Yo cito:

Después de leer mucho, aprendí que hay varias formas de construir el mismo carácter Unicode, por lo que para una comparación eficiente existe un concepto llamado normalización ( http://www.unicode.org/reports/tr15/ ). Después de normalizar con el mismo algoritmo, la representación de cualquier carácter será consistente.

Lamentablemente, existen múltiples algoritmos de normalización y no hay consenso sobre cuál usar. Apple usa NFD, mientras que la mayoría de los otros sistemas operativos usan NFC. NFS no especifica un método de normalización, por lo que OSX no puede realizar conversiones de forma segura de forma inmediata.

Todo lo que tenía que hacer para arreglar esto era decirle a NFS que mis recursos compartidos de NFS usaban NFC. Luego aparecieron todos los archivos con los caracteres impares y se leyeron bien.

Hice esto agregando esta línea a /etc/nfs.conf en la Mac.

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

Funciona perfectamente.


Adición: las opciones nointr,locallocks están relacionadas con la codificación de caracteres, por lo que la solución debería funcionar sin estas, es decir,

nfs.client.mount.options = nfc

Aunque no lo he probado ya que estas dos opciones tienen sentido en mi escenario de uso.

Gracias por aclarar esto, no tiene nada que ver con la codificación de caracteres, por lo que debería funcionar sin él. Pero estas opciones tienen sentido para mí en mi escenario de uso, posiblemente inclusonolock