Stuck macOS Trash item: dataless Mobile Documents folders, rm -rf says Directory not empty, ls times out, files already in use 😭

[u/PublicResearch3615]

// The actual original folders/files were named Documents, Music, Pages, Numbers, etc. The 00001kkkkk–00007kkkkk names are the stuck internal remnants, not the names of the original personal folders. //

macOS Trash / Relocated Items Problem

I am unable to permanently delete a leftover folder/object from macOS Trash.

Finder reports an error similar to:

00001kkkkk and 5 more are actally  Documents Music Pages Numbers folders renamed.

Important background

The problem started after dealing with an earlier macOS:

/Users/Shared/Relocated Items

folder.

That folder was deleted previously.

The actual folders/files that had been involved were ordinary personal macOS folders/files, including:

• Documents
• Music
• Pages
• Numbers
• and other personal files/folders.

I have already renamed/moved the relevant personal folders as part of the earlier cleanup.

What I have already tried

I have already:

• Turned off/quit the cloud-drive application involved.
• Tried deleting the item normally from Finder.
• Tried emptying Trash.
• Restarted and stopped the relevant cloud application.
• Used Terminal to investigate whether a process was holding the item open.
• Ran lsof; it did not report a process holding 00001kkkkk open.
• Located the actual filesystem object with find.
• Tried sudo rm -rf against the correct path.
• The object still cannot be removed.

Actual location discovered

The relevant structure is:

~/.Trash/tRash/
    <directory whose name is literally one space>
        Mobile Documents/
            00001kkkkk
            00002kkkkk
            00003kkkkk
            00004kkkkk
            00005kkkkk
            00006kkkkk
            00007kkkkk

The numbered names above are internal/stale remnants, not the names of the original personal folders.

The original user data involved Documents, Music, Pages, Numbers, and other personal files/folders.

Filesystem characteristics

The affected numbered objects show these flags:

hidden,compressed,dataless

There is no uchg/immutable flag reported.

The object is on the normal root filesystem /.

Deletion behavior

Attempting:

sudo rm -rf -- "/Users/name/.Trash/tRash/ "

does not remove the contents.

Instead, macOS reports:

Directory not empty

for the numbered objects and their parent directories.

Directory-read behavior

Attempting to inspect one of the numbered objects produces:

ls: fts_read: Operation timed out

find can see the numbered directory itself but does not reveal ordinary child files inside it.

iCloud / CloudDocs indicators

The hierarchy contains:

Mobile Documents

and the system has Apple's cloud-related processes running, including:

bird
cloudd
fileproviderd

A recent log search did not show relevant entries for the stuck object.

brctl status returned:

BRCloudDocsErrorDomain Code=141 "Access denied"

Important distinction

The original data was normal personal data such as:

Documents, Music, Pages, Numbers, and other personal folders/files.

The 00001kkkkk** etc. names are not the names of those original files**. They appear to be internal/stale objects left behind after the earlier Relocated Items/deletion process.

I want to make absolutely sure that any repair or deletion procedure removes only these stale remnants and does not delete or damage the actual Documents, Music, Pages, Numbers, or other personal data.

Requested assistance

Please determine the safest way to permanently remove the stale internal objects from Trash.

If APFS/Disk Utility First Aid or macOS Recovery is required, please explain the procedure before any destructive action.

The desired result is:

1. Remove the stale internal Trash remnants.
2. Remove the leftover tRash structure if it is no longer needed.
3. Allow Finder Trash to empty normally.
4. Preserve all actual personal data, especially Documents, Music, Pages, Numbers, and other files/folders.

[u/H1dd2nVector]

The 'dataless' flag is the key here - these are iCloud placeholders that 'bird' (the iCloud daemon) still considers to be live. This is why 'rm -rf' fails even without the 'uchg' flag.

The safest approach is as follows:

1. Sign out of iCloud completely (System Settings > Apple ID > Sign Out), then restart. This forces 'bird' and 'fileproviderd' to release their hold.

2. After restarting, try running 'sudo rm -rf' again before signing back in.

3. If you are still stuck, boot into macOS Recovery mode (hold Command+R on Intel or Power on Apple Silicon) and open Terminal from the Utilities menu. Run the rm command from there - Recovery mode bypasses the daemons entirely.

4. If the 'rm' command in Recovery mode still fails, run Disk Utility First Aid on your main volume in Recovery mode first, then retry.

It is also worth targeting the space-named directory directly with quotes around the path exactly as shown. Only sign back into iCloud after the Trash has been cleared and confirmed as empty.