I have my music and movie collection on a linux server and the file names contain non-ascii characters. This is in itself no problem as the music server also runs on the same server and everything is fine.

The server's locale settings are:

root@lms:~# locale

and the clients (macOS Sierra) are:

09:15:38 ~$ locale

But I am using OS X / macOS on my desktop computer and would like to manage the files (tagging, sorting, ...) by using OS X programs. I have created an NFS share on the linux server as follow:


and mounted on the Apple:

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

My problem is that I can not copy the files with non-ascii characters using Finder (finder tells me

The operation can't be completed because one or more required items can't be found. (Error code -43)

Where error code -43 meand "File not found".

But I can copy the file from the terminal.

This is also reflected as I can not open the file on the external volume by using right mouse click, but I can open the local one which I copied using the terminal, or that other programs (e.g. Metadatics for editing tags) can not see or work with the files.

This whole thing sounds rather strange to me, as macOS and Linux can work with the non-ascii characters (accented characters in particularly), but macOS has problems when accessing on the share?

Is there anything I can do except changing the file names to ascii characters? Are there mount options I should set?

I should mention that this problem is not new in Sierra - it was there under ElCapitan as well.

1 Answer 1


OK - I found here https://discussions.apple.com/message/21199204#message21199204 the answer. I quote:

After much reading I learn't there are multiple ways to construct the same unicode character, and so for efficient comparision there is a concept called normalisation ( http://www.unicode.org/reports/tr15/ ). After normalising with the same algorithm the representiation of any character will be consistent.

Sadly there are multiple normalisation algorithms and no concensus on which to use. Apple use NFD, where as most other operating systems use NFC. NFS does not specify a normalisation method, so OSX cannot confidently convert out of the box.

All I needed to do to fix this was to tell NFS that my NFS shares used NFC. Then all the files with the odd characters appeared and read fine.

I did this by adding this line to /etc/nfs.conf on the Mac.

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

Works perfectly.

Addition: The options intr,locallocks are not related to character encoding so the solution should be workinf=g without these, i.e.

nfs.client.mount.options = nfc

Although I haven't tried this as these two options make sense in my usage scenario.

  • Thanks for clarifying this - it has nothing to do with character encoding - so it should be working without. But these options make sense to me in my usage scenario - possibly even nolock
    – Rainer
    Commented Sep 29, 2016 at 12:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .