Can’t autosave? A cloud might be in the way

Your Mac mostly hides its Unix1 underbelly. You can tap into it as you need, but it mainly drives the system. For many people—perhaps most—the Unix part crops up when you’re dealing with permissions. Permissions refers to the access that files and folders (directories) allow with respect to specific registered users, groups, and special system roles.

My friend Larry, whom I previously helped delete his email account, had a perplexing permissions problem. When he saved changes to a Keynote presentation, he was told that he lacked permissions:

For the longest time, some Keynote files will give me an error message that they can’t be autosaved (or manually saved) because I don’t have permission. I’m instructed to go to File: Get Info [in the Finder] to change permissions, but they appear correct to me.

Let’s work through this problem. (This time, I didn’t accidentally help Larry delete all his presentations.)

This dialog is mystifying for most users: of course, I have permission to save!

Motherboard, may I?

Given that macOS explicitly stated that this was a permissions problem, I went in assuming that this was the case. Here’s a quick way to troubleshoot this problem:

The Get Info window lets you see if permissions are set, and override them for non-startup volumes.

Check if it’s an external drive. This can often crop up if you’re using a volume other than the startup volume. (That volume could be configured as part of an internal or external physical drive.) The startup volume assigns permissions based on roles, like administrators, and accounts, as for each user and for the guest account (if enabled). All other volumes are generally available to every macOS user. However, unless you have a specific reason to restrict access, it’s best to avoid problems: in the Finder, select the volume, choose File: Get Info, click the lock icon and authenticate if required, and check the box “Ignore ownership on this volume.”

Check the enclosing folder. It’s possible that an enclosing folder for a file has different permission settings than the file within it. Select the folder in the Finder, choose File: Get Info, and examine the Sharing & Permissions section. Are you shown as “name (Me)” with Read & Write next to it? Terrific. If not, add yourself by clicking the + sign at the bottom of the window or using the Privilege pop-up menu.

Check the file. Repeat the process above by selecting the file and choosing File: Get Info. Check permissions and fix if needed.

(A tip: You can bring up a contextual Get Info window that reveals whatever is selected in the Finder by pressing Command-Option-I. If you need to examine a lot of file, folder, or volume information, and don’t need to compare the contents of different Get Info dialogs, it’s more efficient.)

However, Larry found his permissions were correct in all three cases. There was one more thing to check: could it be an app-based restriction? While access permissions are tied to files, folders, and volumes, macOS also imposes limits on how apps interact with stored files that are outside a few defined areas, like the Documents folder in your Home folder.

The Full Disk Access option is overkill, but may be necessary with some apps so that they can save anywhere on any volume.

macOS can limit or allow permission for a few preset folders or volumes.

Go to System Settings: Privacy & Security and check to see if the app getting an autosave error is listed in Full Disk Access.[^full] If not, you can click the + icon at the bottom and select the app from the Applications folder, then enable its switch. (This may require quitting and relaunching the app if it’s already running.)

(Another tip: Most apps don’t require access to everything on all your volumes. However, Apple offers only the distinction between allowing access to a limited set of folders and any removable volume, or the entire set of available volumes.)

That didn’t help, either. Something else was at work. Could it be… the cloud?!

Murky actions by some cloud-hosted volumes

When I started down this path with Larry, I didn’t realize that he was storing the files on his Google Drive. This didn’t seem like it should be a problem, because you can autosave to Dropbox and iCloud Drive. (I haven’t tested Microsoft OneDrive’s Finder cloud volume or other companies’ offerings.)

Apparently, Google is an outlier. Because of how Google recognizes files stored on Google Drive, the incremental autosave snapshots interfere with Google’s file management. Or at least that’s the theory—Google doesn’t document the problem or offer advice.

The “Ask to keep changes…” option, when turned on, prevents autosaving.

The only way around this is to choose a “nuclear” option, which is to disable autosave in all your apps. Apps with support for autosave will continuously write snapshots (or “journals”) to locally mounted volumes formatted with HFS+ or APFS. (Windows-compatible volumes lack the support needed.)

To change autosave behavior, go to System Settings: Desktop & Dock: “Ask to keep changes when closing documents.” This setting is disabled by default, which allows autosaving incremental changes. You use File: Revert To for stepping back to earlier revisions. If you enable it, files are saved only explicitly when you choose File: Save or click Save when closing a document or quitting an app.

The solution for Larry was to lose the Google sync—a useful option for him—and save to a volume that supported autosave.

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

Apple has even obtained Unix certification (since 2024) against a particular standard by which Unix is measured. ↩