nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Child Item

Reproducible sync bug — files with com.apple.ResourceFork xattr silently fail sync to Linux client

nicole65

I’m reporting a reproducible bug, not a usage question, and would like this escalated to engineering.

Summary:
Files with the macOS extended attribute com.apple.ResourceFork (no namespace prefix) fail to sync from a macOS Dropbox client to a Linux Dropbox client. The Dropbox status indicator on both ends reports the account as fully synced, with no error shown. This affected roughly 3,000 files in my account, all large media files (TIFF, NEF, JPG) spanning 20 years.

Why this matters:
Dropbox documentation lists user.com.apple.ResourceFork as a supported extended attribute. However, the attribute as actually written by macOS (e.g. via xattr -l on the file) appears without the user. namespace prefix — simply com.apple.ResourceFork. Files carrying this unprefixed attribute are silently dropped from sync to Linux, rather than synced without the attribute, or flagged as an error.

Steps to reproduce:
1. On macOS, take any file with an existing (even empty) com.apple.ResourceFork extended attribute, in a Dropbox-synced folder.
2. Confirm via Dropbox status that the account is “up to date” on both macOS and Linux.
3. Confirm the file is present on macOS and in the Dropbox web interface, but absent on the Linux client.
4. On macOS, run: xattr -d com.apple.ResourceFork “/path/to/file”
5. The file then syncs to Linux normally within the expected timeframe.

Impact:
This bug is dangerous because it fails silently. The sync status never indicates a problem, which means anyone relying on Dropbox as a source of truth across platforms (e.g. for backup, deduplication, or migration work) could lose track of files without ever being warned. In my case it took two days of independent diagnostic work to identify the root cause, since support was unable to engage with the technical specifics of the issue.

What the Dropbox engineering team should do:
1. Confirm whether this is a known issue with the Linux client’s handling of unprefixed com.apple.ResourceFork attributes.
2. At a minimum, surface a sync error/warning when a file is skipped for this reason, rather than reporting “up to date.”
3. Ideally, support syncing the file’s data fork regardless of this attribute, since the attribute is legacy macOS data with no relevance to Linux.

Happy to provide example files, xattr dumps, or further diagnostic detail if useful.

Find more posts tagged with

Sync

Mac

Linux

Accepted answers

All comments

Jay

Hi @nicole65, thanks for bringing this to our attention.

As this involves a lot of specific detail related to file attributes, I'd recommend contacting the support team directly for them to forward it to the appropriate team.

You can contact them directly via this link, and they'll be able to assist further.

nicole65

Thanks for that link, but that gives me an AI chatbot that is unable to escalate to engineering. The Ai chatbot suggested that I file a bug report, but the bot was unable to give me a pointer where to file a bug report. So how do I do that?

Hannah

Hey @nicole65, the chatbot won't be able to escalate you directly, but you should be able to request to open a ticket with our support team or chat with a support agent.

Can you request that from the chatbot and let me know if it works?

nicole65

No, it didn’t offer that option. I have now pasted the text of this post into the support ticket that I already opened earlier, when I first encountered this issue.

Здравко

Hi @nicole65,

What you reported is an old known bug, but as most of the Linux related things, this bug didn't accommodate too much attention (no any attention actually from Dropbox support). The scripts I posted there are even no readable (the entire script is a single line now) after new community forums edition came up. The only way is to fix your issue yourself if somebody from Dorpbox doesn't decide to refute me (something I would be very glad if happens).

Good luck… to all of us!

nicole65

O wow, that's really a head-banging story. That old post ran for 2 years, I found the solution in 2 days.

What is not explicitly mentioned in that other discussion is that the problem is com.apple.ResourceFork (it only talks about "some file attributes"), which apparently is a legacy macOS-thing that doesn't serve any purpose anymore, but some programs still create that attribute for historical reasons. It's relatively easy to strip that attribute from all affected files, after using rclone check to create a list of the affected files, but obviously that only works if you have access to a machine that does sync those files. Fortunately I still had my macbook available, so I could do the repairs there myself, otherwise I would be stuck.

I'm not sure if there are other extended attributes also causing problems, but in my case, it doesn't seem like that.

Здравко

The problem is that Dropbox application on Linux downloads the files actually, but for whatever reason when (at the end) it comes to move downloaded files from cache to their final destination, files with attributes got wiped out. After that the "sync" process start anew ans so few more times. After number of tries the application stops trying.
This is definitely application BUG!.. It could just ignore the attribute (whatever is it or how many they are) and move the already downloaded file (as it does for all others)… but it doesn't.

Hannah

Hey Nicole, I just located your ticket and passed your comments here along to the team, so please wait for their reply the soonest possible.

Здравко

Hi @Hannah,

Is there some chance this issue be fixed finally? 🤔 (as already mentioned after more than 2 years)

Featured Links

Child Item