After many years of relying upon Dropbox as my go-to cloud solution, I’m saying good-bye due to an issue arising from intractable mis-set file permissions. After five hours on the phone with an Apple Support supervisor named James, he determined that the problem was found with files accessed via the Dropbox integrated Finder app. Bottom line: If you share files between two computers, do not use the Dropbox integrated Finder app with a university-issued computer.
It seems that university security policies were applied to all files on my Dropbox account, probably because I had the Dropbox integrated Finder app installed. Permissions problems arose making those Dropbox files virtually unusable when accessed from a non-university computer which shared that Dropbox account and similarly used the integrated Finder app. Even when copying my files from Dropbox over to the Documents folder of my non-university computer, using the integrated Finder app, the files remained unusable due to the permissions problems.
Here’s the story, and the obscure fix that eventually proved successful:
I have long been a huge fan of Dropbox’s integrated Finder app, which makes accessing files on Dropbox as simple as using the sidebar in a Finder window. In contrast, I find Dropbox’s web interface very cumbersome.
Over the last year I have kept several terabytes of files on Dropbox so that I could access them both from my university computer and from my own computer. As hard drive spaces on university computers shrink, working with cloud storage becomes more critical. To be clear, I was using Dropbox not for backup(*), but to share files from two computers (my own and the university-issued one), as well as from my iPhone and my iPad. In other words, I adopted a cloud-centric approach to computing that let me work from whichever device seemed most appropriate for the task or the occasion.
But sometime last year, the university replaced my university-issued computer with one that had some new security or user group policies applied. Some combination of the university policies and files stored on Dropbox resulted in all of the files on Dropbox accumulating extra permissions that looked like this:
With these permissions, I became unable to save, move, or delete files. Copying files was possible, but not simply moving them or deleting the originals once they were copied. Using the Get Info dialog box (and unlocking the little lock in the lower right corner), I could manually set the permission for the first “everyone” from “custom” to “Read only.” Then the file could be modified, saved, moved, or deleted (in most cases). But I have many thousands of files and setting permissions manually like this is simply not a viable option. In addition, the option to delete the extra users (e.g., the extra “everyone” accounts) appeared dimmed or disabled (even after unlocking), so it was not possible manually to clean up the permissions as one would wish.
There should be only one “everyone,” set to “Read only.” The “custom” setting for everyone is likely the result of a security policy applied by the university to my university laptop, which carried over to Dropbox files because of the Dropbox integrated Finder app.
For files to function properly, permissions should look like this instead:
My own computer, which I use for non-confidential research and personal files, is a 16-inch M2 MacBook Pro with updated Sonoma OS and a very large capacity internal hard drive. I am the administrator and it has never connected to university networks nor has ever been managed like the university-issued laptop I use on campus.
When my new university-issued computer came with just half a TB hard drive, I decided to move my (non-confidential) research files entirely to my personal laptop, and abandon my cloud-centric approach. I have invested in a nicer phone and am no longer using an iPad. And I have spent a total of about two of the last six months in rural areas where there was no reliable wifi, so working from my computer’s hard drive instead of the cloud would have been more convenient. So I copied all my files over to my own internal hard drive. I will work simply from my personal computer rather than from the cloud with multiple devices. (This takes me back to the old Mac as a hub days — remember iLife? — which I gave up for a cloud-centric approach many years ago.)
So I dragged all of my Dropbox files over onto the internal hard drive of my personal computer, via the Dropbox integrated Finder app. And all these permissions issues did not go away; the extra permissions came over with the files even when they were relocated to my Documents folder.
On the phone with Apple support, we tried all kinds of methods to correct the permissions without success. The “Apply permissions to enclosed items” command did not work. Nor did a variety of commands issued in the Terminal app, some of which are shown below (click to enlarge). We executed those commands in Recovery mode as well, but still no success.
I’m grateful that James, the Apple Support supervisor that evening, did not give up. About five hours into the call, he suggested I re-download the files from the Dropbox website, using my web browser rather than the integrated Finder interface. Voila! Downloading a test file from the Dropbox website resulted in the removal of the unwanted permissions. The very same file shown above (when copied over in the Finder), now looked like this (when downloaded through Safari):
Permissions fixed! On the basis of that test, I had a path to follow. Over the last few days, I re-uploaded all of my files with bad permissions back to Dropbox, and then downloaded them via the Dropbox web interface. It was time-consuming due to bandwidth limits, sync times, and maximum allowed items to download at once, but all of the files are now on my computer’s internal hard drive with correct permissions.
Unbelievably, I am now good to go and lost no files (**Mellel) (***Pages).
One more thing: The old directory of files, which I had transferred over to my internal hard drive via the Dropbox integrated Finder app, still needed to be deleted, and it was consuming an inordinate amount of space. When trying to delete the files, a dialog box appeared exhorting me to first set the permissions of each file manually before trying to delete them!
Ha! Obviously this would not work for a directory containing many thousands of files. James again came through — in a second support call, this time “only” three hours long! We turned off syncing with iCloud Drive, and then deleted the files through signing into iCloud on the web. iCloud on the web could ignore the permission restrictions and delete the files. Magnificent. (There were some tricks to this, and we also deleted the “home/iCloud Archive” directory just to be sure, but eventually it all worked.)
I’ve learned a valuable lesson: the university’s security policies and the Dropbox Finder app do not play nice with each other. I will no longer even attempt to share my research files with the university computer, but will work simply from my own computer’s internal hard drive. Of course I will continue to use the university computer for Office apps and Teams, university email and documents, and tasks that require confidentiality such as student records and correspondence, but nothing more than necessary. For university file sharing I’ll use Sharepoint (or a University-owned Dropbox account via the web interface only, but neither shared with my personal laptop). I’m adopting a “Two Worlds” approach to computing, with my presentations, writing projects, digital scholarship, and other research solely on my personal computer. My nice new North Face backpack can carry both laptops, although due to its extra weight, I’ll leave the university laptop on campus whenever possible.
Thanks to the university security measures not playing nice with the Dropbox Finder app, and the Dropbox web interface not playing nice with some file formats, it’s time to say goodbye Dropbox my old friend.
* For backup, don’t use Dropbox. I hadn’t, and luckily, because I use Airdrop. Dropbox takes over the Downloads folder on a Mac if given permission to conduct backups, making AirDrop impossible. If you have used Dropbox for backups, first disable it and then you will be able to use AirDrop again. Instead of Dropbox, for backups I use BackBlaze, and external hard drives with Time Machine and Carbon Copy Cloner. With the money I am saving from canceling Dropbox, I’m raising my iCloud storage level so that my newly enlarged Desktop and Document folders can fully sync to iCloud Drive. My university-issued laptop does not connect to my iCloud Drive (I’m keeping it quarantined in its own small self-contained world), but through iCloud my phone and personal laptop will still work together.
** Mellel: Upon completing the downloads described above, almost all file types were working. But Mellel files did not make the roundtrip to Dropbox and back again. Mellel offers two formats: I save Mellel documents as packages, which speeds up the autosave process. (I have not tested the other format.) My Mellel documents have worked when copied to and from Dropbox via the integrated Finder app, but when downloaded from Dropbox through the web browser, the Dropbox zipping process involved evidently made them unable to open. The same downloading process that stripped away the unwanted permissions also stripped away something of the file format. The downloaded files do have the correct permissions, but they display this error message when I attempt to open one:
Curiously, here’s a workaround: If I compress the Mellel file to create a zipped version of it, then decompress the zip, the file appears with the name “dropbox_download.mellel”! (The name incriminates the culprit here.) Yet success: the document now has correct permissions; I can now restore the original filename; and it now opens normally in Mellel. Hooray!
Mellel is my favorite word processor for longer projects and these files are very valuable to me. Thankfully they do not number much more than a hundred, and this workaround to fix them is not difficult. (If you haven’t tried Mellel give it a look; for academic writing nothing is better.)
*** Pages: Older pages documents, from about 2012 and earlier, were also corrupted by Dropbox’s zipping download process. While still on Dropbox, the files with corrupted permissions could be opened after manually correcting the permissions. If saved, they would be upgraded, still on Dropbox, and then they would download fine. But if not opened and upgraded while still on Dropbox, then they would be damaged during the browser-mediated downloading process and be no longer openable by Pages or any other app. Sometimes they would pick up a “.pages-tef” filename suffix, which seems to refer either to an older version of Pages or possibly Pages for iOS. (While I did work with Pages on an iPad, I think most of these files were older versions of Pages for the Mac, so the -tef extension added during the browser-mediated download is a mistake.) The trick of compressing and decompressing a file that worked for Mellel documents does not work for these old Pages files (the archive utility hangs up and cannot complete its attempt to decompress them). If opened in some other text editor, these old Pages files display a name like the Mellel files that incriminates Dropbox; something like “dropbox_download_…” (I don’t remember exactly).
So far, I have not encountered this problem with old Keynote and Numbers files but I would not be surprised if it creeps up at some point, especially with files created before 2012.
So my path for recovering older Pages (or iWork) documents is to save an external hard drive of a backup from last summer before these problems arose (before the security policy was applied). That backup will contain all of my older files. (But if one didn’t have a backup, one might still download one’s Dropbox files onto an external hard drive directly from Dropbox using the integrated Finder app, which transfers functional Pages files but with bad permissions. Then one would keep that on an external hard drive for future use, when one could manually correct them as needed even though one wouldn’t be able to get rid of the extra permissions accounts. Or, if one could find them all now, before canceling one’s Dropbox account, then one could upgrade them on Dropbox and then re-download via the Dropbox website to avoid the file permissions problem. That would resolve the problem.)
In summary, files transferred to my computer through the Dropbox integrated Finder app carried the bad permissions. Files transferred to my computer through the Dropbox web downloading interface did not carry the bad permissions, but were corrupted if their file types were older (e.g., Pages) or packages (e.g., Mellel). Cloud computing is hard, and neither method of accessing files on Dropbox works without issues.
If I want cloud computing to work “like a Mac,” I’d better stick with iCloud.
(Except with iCloud, documents are continually being offloaded to the cloud even when hard drive space remains clear. I often work in places without wifi available, so this is quite inconvenient — and for a month last fall, I was in a remote location where I couldn’t even use my phone as a hotspot. I have “Optimize Mac Storage” in Settings checked, which is supposed to keep files on the drive until it begins to run out of space. I hope Apple will soon add a “Keep item available offline” feature to iCloud.)
