I'm getting this strange issue when trying to play MP3s containing Unicode characters (accents) over an NFS on Mac OSX, it's all good over AFP, but I'm setup with NFS because it's a linux server on the other end.

This is my disk utility setup:

*nfs://192.168.1.112/Music*

Advanced mount parameters:

*-P , nolocks nosuid*

The strange thing is that I can see those files in the finder ( with the accents .. ) but I can't play them! So I'm wondering if it's an unicode issue, since I can see the files properly or a permission issue since I can't play them, but them it wouldn't make sense that I can't play ONLY the files containing accents ..

Thanks

  • 1
    Have you tried a different MP3 player? Maybe it's just a bug in that one MP3 player, choking on those file names. – Spiff Feb 27 '11 at 8:05
  • Try VLC! – Mateen Ulhaq Feb 27 '11 at 9:38
  • How do you play them? QuickLook in Finder? iTunes? Get Info dialog's preview (also Finder)? Does one of the other ways mentioned work? Does it work when you copy the files to your local disk (still with accents in the file names)? – Daniel Beck Feb 27 '11 at 11:02
  • @muntoo Great suggestion. VLC doesn't even get spaces in file and folder names right on OS X. (Playing works fine, but the proxy icon is beyond broken). – Daniel Beck Feb 27 '11 at 11:03
  • That was using VLC !! :) Quicktime player ( or preview ) wont work either, it says that the file doesnt exist even though the finder sees it fine and it definitely exists . I'm thinking about permission issues, but why would it just be for files with accents in it. Makes no sense to me ... – fingertwist Feb 27 '11 at 11:16

Use the nfc option in your nfs mount:

nfc Convert name strings to Unicode Normalization Form C (NFC) when sending them to the NFS server. This option may be used to improve interoperability with NFS clients and servers that typically use names in the NFC form.

MOUNT_NFS(8)

The reason:

Unicode is a complex standard. One of its elements is encoding. There exist several of them. Linux is using UTF8 precomposed while OS X uses UTF8 decomposed, this result in eg the glyph "ä" being encoded in different bytestring on Linux and OS X.

Source: https://discussions.apple.com/message/12045309#12045309

Example of an automount entry in my workstation:

iss:~ root# cat /etc/auto_nfs
3TB    -fstype=nfs,resvport,nfc,vers=4,soft,intr,rsize=32768,wsize=32768,noatime,retrans=3,proto=tcp nas.local:/nas/3TB
  • 2
    Horrible truth is that you may see files disappearing in Finder from nfs mounts with the nfc option if they have special characters (e.g. ä), and they were previously copied to the server using a mount without char translation, rsync without the --iconv=utf-8-mac,utf-8 option, or similar. The horrible part is that the NFD char on the server may look exactly the same in an SSH session as the NFC one, and that both will show '??' instead of the char in a local shell. Both can exist simultaneously, but it may be that ä != ä and ?? != ?? in the same terminal session. A nightmare to clean up. – DanielSmedegaardBuus Nov 7 '14 at 10:21

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.