A few of those using my free utility PermissionScanner continue to see conflicting reports on whether some files are writable. The underlying problem could affect other apps by preventing them from being able to open files. Although this seems unusual, this could cause bugs elsewhere.

The problem

When software needs to write to a file, it may use one of the two tests provided by the system to see if that file is writable, before trying to open the file for writing. On two Macs running macOS 10.14 and 10.15, four preference files in ~/Library/Preferences/ are persistently being reported as not being writable, despite having correct permissions and not being locked. If other files were to have similar behaviour, this could result in software being unable to write to them, causing an error.

What the user sees

An app or other software tries to open a file which it needs to write to, but is told that it can’t. It therefore either returns an error to the user, or (if the error condition isn’t properly trapped by the software) it might crash as a result.

Which files are affected

The two reports that I currently have from users concern the same four files in the Home Preferences folder at ~/Library/Preferences/:

• com.apple.mail-shared.plist
• com.apple.homed.notbackedup.plist
• com.apple.universalaccess.plist
• com.apple.homed.plist

On all other systems, scanning these returns that they are writable, as expected.

What can the user do about this?

The only user controls, either in the Finder’s Get Info dialog or in Terminal, allow the user to change permissions and unlock the file. As the permissions are correctly set and the file isn’t locked either, there are no controls which the user can change.

Note: please ensure that you have given PermissionScanner Full Disk Access in the Privacy pane, as detailed in its documentation. According to Jeff Johnson @lapcatsoftware these four files are given special privacy protection by the kernel. If you don’t give Full Disk Access, then they should return as not being writable, although Apple doesn’t seem to have documented this anywhere, or even mentioned in passing in a WWDC presentation.

If you encounter this situation, please let me know, either by commenting below or by email (see the About page). Please use Verbose mode in PermissionScanner 1.7 to confirm this, and let me know which files are affected in which version of macOS.

Technical: Which calls are affected?

The calls in question are FileManager.default.isWritableFile(atPath: path) and URL.resourceValues(forKeys: [.isWritableKey]). Both cases return a Boolean value of false, despite .ownerAccountName returning the current user, .posixPermissions returning octal 600, and .immutable returning false. These are all using Swift 5 in Xcode 11.3.1 for macOS 10.12 and later.

Technical: How to work around this

Avoid testing using the above FileManager or URL calls, instead proceeding directly to open the file for writing when required. Ensure that errors from that are properly reported to the user.

Has a bug report been filed?

No. I am unable to reproduce this problem here, so cannot file a report in Feedback Assistant. If you encounter this problem and are able to file a bug report with Apple, please do so.

I am extremely grateful to Adam and Al for reporting this problem, and to the redoubtable Jeff Johnson @lapcatsoftware for his comprehensive knowledge of macOS.