I was clearing a music folder in my external drive and found a directory I can't delete no matter what I try.

If I put it in trash bin via GUI

The operation can’t be completed because the item “folder” is in use.

If I use rm -rf to remove it via terminal

$ rm -rf folder/
rm: folder/: Directory not empty

If I use ls -la to check its content

$ ls -la
total 512
drwxrwxrwx  1 user  staff  131072 Jan  3  2017 .
drwxrwxrwx  1 user  staff  131072 Jan  3  2017 ..

If I use rm -i * within the folder

$ rm -i *
rm: 03 - Ēlusion.mp3: No such file or directory

If I use sudo lsof +D folder/ to check if any files are opened

Nothing returns on program exit.

If I use Disk Utility to repair (first aid) disk and volume

Health check passed so no repair was initiated.

If I reboot macOS

The issue persists.

Additional info:

  • I can move the folder within the drive, but not to another drive.

  • I can rename the folder.

  • ls -i *.mp3 returns ls: 03 - Ēlusion.mp3: No such file or directory, same as rm -i *.mp3.

  • The file doesn't show up in Finder, that's confusing part, whatever filename display issue Terminal could have (I always set it to use Unicode - UTF-8), I think there are more force at play.

In response to questions, nope, ls -ib doesn't return anything.

$ ls -i
$ ls -ib
$ ls -laib
total 512
2762318 drwxrwxrwx  1 user  staff  131072 Jan  3  2017 .
2685260 drwxrwxrwx  1 user  staff  131072 Jan  3  2017 ..

So apparently there is something in it but ls -la couldn't see it, while rm -i is being weird with filename?

get info via GUI context menu did confirm there is 1 item in the folder, but with zero byte, and certainly doesn't show up in finder.

I am not sure what to do at this point. Help much appreciated!

(Using 10.13.4 + ExFAT on external drive)

  • 1
    Have you considered backing up all the stuff you want - probably already backed up anyway... then completely re-formatting that drive to start over?
    – Solar Mike
    Jul 12, 2018 at 19:48
  • Does ls -b show the file? If so, you can ls -bi to get the inode and follow the below answer, or alternately just copy the filename in the -b output.
    – Reid
    Jul 13, 2018 at 4:36
  • I believe the core problem is not with filename, ls -bi *.mp3 show the same result as shown in OP.
    – bitinn
    Jul 13, 2018 at 4:42

2 Answers 2


The problem appears to be caused by a file named 03 - Ēlusion.mp3 located within the directory named folder.

Because Terminal.app is unable to render diacritical marks in file names--well, it is, but that's beyond the scope of providing the simplest solution for you--it hides its failure by hiding the filename (something unheard of by me before now; perhaps its High Sierra's changes to /.file, /.volfs and 64-bit inodes? Wait-- never mind; your edit to your question tell me I misunderstood you.) Anyway, the file's existence is known, along with the ironical contention by the Finder that it doesn't exist. Obviously, it does. Here's how to change that:

First, determine the file's inode number. In Terminal.app, cd to the directory "folder" and issue this command: ls -i *.mp3

Copy the number string of the inode provided in the left-hand column of the response, which will be something like

12345678 03 - E ̄lusion.mp3

--and put it into this command, which will rename it to something the terminal can render correctly:

find . -inum 12345678 -exec mv {} deletemenow \;

--giving you the file "deletemenow" in the folder "folder," both of which you may dispose of in whatever way best suits your fancy.

  • Wow, that's an impressively terrible bug. Jul 13, 2018 at 0:58
  • 2
    I don't think this is accurate. The terminal may hide single characters that it cannot render, but it will not remove the entire line of text.
    – user101978
    Jul 13, 2018 at 2:14
  • 1
    @duskwuff Either way it seems that filename is causing issues, so this is a potential solution regardless.
    – JAB
    Jul 13, 2018 at 3:14
  • Sorry but the issue seem more complex than this: I tried $ ls -i *.mp3, it returns ls: 03 - Ēlusion.mp3: No such file or directory.
    – bitinn
    Jul 13, 2018 at 4:22
  • 1
    Can you just run ls -i within the directory to prevent the shell wildcard expansion from interfering?
    – nohillside
    Jul 13, 2018 at 4:40

It took me a long time to come to this summary, but I think it's the definitive answer.

The cause of my issue is a well-known one:

OS X is the odd one out, both in that it normalizes file names and in that it uses NFD instead of the more common NFC.

Historically (not that old, pre 10.11 era), OS X + HFS+ enforces NFD form on all filenames, and you will only get NFD result from commands and system calls.

Then things starts to change, in 10.11, some system call results are normalized to NFC, which puts it inline with Windows and Linux, but at the expense of breaking some programs that expect NFD on OS X.

But since the introduction of macOS 10.13 + AFPS, the behavior changes again: Apple decides it wants to normalize to NFD on display and system calls, but leave the original filenames as it is (so both NFC and NFD are supported, but if you select the filename in Finder or copy ls result in Terminal, you get NFD form).

This is all great, until you put a file with NFD filename in an external drive using exFAT (as it's the only cross-macOS/Windows format with 4GB+ file size support): macOS 10.13 somehow believe your file must be in NFC format, so it bugged out.

In fact, here is a quick test, I have a folder in Windows on my exFAT drive with 3 files:

enter image description here

  • test.mp3
  • Ēlusion.mp3 (Ē in NFC)
  • 03 - Ēlusion (Ē in NFD)

(You can copy the exact unicode here)

When I mount them on my macOS, this is what I see:

enter image description here

and ls -laib result:

$ ls -laib
total 46592
2762318 drwxrwxrwx  1 user  staff    131072 Jan  3  2017 .
2685260 drwxrwxrwx  1 user  staff    131072 Jan  3  2017 ..
1572961 -rwxrwxrwx  1 user  staff  11672464 Aug 23  2014 Ēlusion.mp3
1572871 -rwxrwxrwx  1 user  staff  11672464 Aug 23  2014 test.mp3

As you can see, the NFC file is present but NFD file is missing.

Even if you are aware of the NFC/NFD problem on OS X, you might not expect exFAT external drive to face this issue in the opposite way (NFC is fine, but NFD is pant-on-fire).

But what could have caused my music file to use NFD filename in the first place:

  • I originally downloaded this music file on 10.9/10.10 with an older Mac, which enforces NFD filename.
  • At some point I move them away to a Windows + NTFS drive, which doesn't enforce NFC/NFD, so original NFD filename is preserved.
  • Now I want to move this file back to my macOS 10.13 + APFS using an exFAT drive (exFAT supports the same UTF-16 convention as NTFS).
  • Hell break loose.

I could have copied the file via networked drive or TeamViewer, and it would be fine, but exFAT is triggering this bug on macOS.


  • Unicode filename is still a threat.
  • You actually need an Windows/Linux to fix this issue (if the situation is your file are on an exFAT external drive).
  • @bitlinn: Click on the second link in my comment addressed to duskwulff and try out the Apfelstrudel unicode normalisation tool you'll find there. Very useful for APFS, pointless with exFAT. Or is it...?
    – Doc G.
    Jul 13, 2018 at 6:42
  • 1
    @DocG. this issue is a bit more complex than I initially thought, but I have updated my answer, again!
    – bitinn
    Jul 13, 2018 at 8:17
  • Yeah, I thought you might end up doing that. See my earlier comment about Error 36 and do a web search for something like "move files back and forth windows mac error 36" for more information on separating file attributions on non-HFS systems. This has been (another) known MacOS / OS X file naming problem since System 10.6 arrived. Between the Unicode normalisation and the dot_underscore attribute separation, you experienced a heck of a double bug. I doubt if the dot_clean command stood a chance.
    – Doc G.
    Jul 13, 2018 at 14:06

You must log in to answer this question.

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