By Glenn Fleishman

March 16, 2026 9:30 AM PT

Stop ghosting me! When ‘Ignore ownership’ is ignored

A powerful tool in the Finder arsenal is a simple checkbox: “Ignore ownership on this volume.” This option appears when you select any locally connected volume on your Mac that isn’t the startup volume and choose File: Get Info. Permissions controls who and, more importantly for this column, what can access data.

When you check the box, you override the normal permissions settings for a volume, which otherwise may restrict reading, writing, and viewing of folder contents to specific users or groups. Even if you’re the only user of your Mac, this can still cause problems, because your logged-in user doesn’t have permission to read and write everything.

While you can typically override a prohibited operation by entering your administrator password when prompted, that doesn’t always work. And any software that needs unattended access to a folder or volume can be denied, sometimes silently. I discovered a problem with this when Time Machine told me on my laptop that it couldn’t perform a backup to a Time Machine-designed folder on my Mac Studio’s external volume.¹

When I checked this external volume, it was marked as read-only. Using Get Info, I saw that the “Ignore ownership” checkbox had been… ignored! It was now unchecked. Permissions are divided into owners and groups, and the owner was system, which is a privileged user, and allowed Read & Write. One group was listed as wheel, which is a special group that system belongs to, and marked as “Read only.” The everyone group was also included, and also set to “Read only.”

Peculiar.

The Transmit is coming from inside the app

Looking at log data, the only clue appeared to be a lot of errors with Panic’s Transmit file-transfer app:

2026-02-27 08:55:06.561417-0800 0x1ed4930 Error 0x0 0 0 kernel: (Sandbox) System Policy: Transmit(16376) deny(1) file-read-xattr /Volumes/EvoLution 8TB/.Spotlight-V100

It looked like Transmit couldn’t read a number of files on the external volume in question during some routine operation. I had a tab open in Transmit passively displaying that volume’s contents, as I had downloaded a remote file to a folder on it. Apparently, Transmit polls local volumes in the background to check contents.

The answer was found in macOS’s app privacy controls, which prevent apps without permission from accessing all kinds of data, organized into categories in System Settings: Privacy & Security. I’d recently updated Transmit, and this apparently reset access in the Full Disk Access section of Privacy & Security, even though I know I had previously granted access.

Another clue was in the /var/db/volinfo.database file, which I didn’t know existed before researching this problem. This file contains a list of volumes by their Volume UUID (Universally Unique Identifier), which is how macOS ensures that two identically named volumes don’t conflict, as they have unique IDs at the system level. A 00000001 indicates permission is not ignored; a 00000000 means it is ignored!

You can find this datum most easily in Disk Utility: select the volume, then click Info. Under “File system UUID,” you’ll see the number. This may be a short string of hexadecimal (base 16) digits for an HFS+ or Apple RAID volume, or a long one for APFS volumes. For instance, one APFS volume I was having trouble with has the UUID 92EA5511-1DD7-3881-84B9-ED0637645FC2.

The volinfo.database file isn’t updated when “Ignore ownership” changes; instead, it’s appended. Only the last state is referenced at startup, but it’s a strange way to manage this file. When I examine it, I can see the thrashing of the ownership state:

92EA5511-1DD7-3881-84B9-ED0637645FC2: 00000001
92EA5511-1DD7-3881-84B9-ED0637645FC2: 00000000
92EA5511-1DD7-3881-84B9-ED0637645FC2: 00000001
92EA5511-1DD7-3881-84B9-ED0637645FC2: 00000000
92EA5511-1DD7-3881-84B9-ED0637645FC2: 00000001
92EA5511-1DD7-3881-84B9-ED0637645FC2: 00000000

When I looked at the Full Disk Access panel, sure enough, Transmit was disabled. I enabled it and expected to now be rewarded with the read-only status no longer mysteriously appearing.

Sadly, it wasn’t that easy.

A double negative proves to be positive

The next day, the volume is back to read-only. This time, however, I notice that, even though there’s no datestamp in the volinfo.database file, it updates whenever it’s modified. So, using ls -l /var/db/volinfo.database in Terminal, I could see that at 11 p.m., it changed back to read-only. After a little bit of contemplating what might be running at that time, I realized it was Bombich Software’s Carbon Copy Cloner.

While I use Time Machine and Backblaze, I also perform a clone of my startup volume using CCC as extra duct tape on top of my suspenders and belt.

I looked through CCC’s settings and found “Don’t preserve permissions” under Troubleshooting Settings. That certainly seemed like it could be the issue. I also found that I could use a Postflight option to set a shell (or bash) script that could run after the clone update was complete.

#!/bin/bash
sleep 5
vsdbutil -a /Volumes/EvoLution\ 8TB
mount -u -o noowners /Volumes/EvoLution\ 8TB

That script uses the vsdbutil utility to restore the volume’s status to the correct value. And then the mount operation reloads permissions in place. It worked!

But in the meantime, I sent an email to Bombich and heard back from the eponymous Mike Bombich, who said that I had created a backup job that had a conflict: CCC has to enable specific ownership (not “ignore”) on the volume it’s writing to because I was backing up a startup volume. Without ownership enabled, a full restore wouldn’t work. The issue of “preserving permissions” is about the permissions on the source volume, not the destination volume.

The short answer was that I needed to check the “Don’t preserve permissions” box after enabling “Ignore ownership” on the external volume to prevent the external volume from becoming read-only. I don’t know why this just started to crop up, but this is clearly the issue.

Mike also helpfully noted that my backup wasn’t restorable for a variety of reasons, and I’d be better off repartitioning my striped RAID external drive to create a standalone APFS volume that CCC could clone directly to. Mike’s been at this a long time!

For further reading

If you’d like to learn more about using commands in the Terminal app, I’ll be darned, but Joe Kissell has a freshly updated book on the topic, Take Control of the Mac Command Line with Terminal, revised January of this year.

[Got a question for the column? You can email glenn@sixcolors.com or use /glenn in our subscriber-only Discord community.]

[Glenn Fleishman is a printing and comics historian, Jeopardy champion, and serial Kickstarterer. His latest book, which you can pre-order, is Flong Time, No See. Recent books are Six Centuries of Type & Printing and How Comics Are Made.]

If you appreciate articles like this one, support us by becoming a Six Colors subscriber. Subscribers get access to an exclusive podcast, members-only stories, and a special community.