Bash Scripts don't write to defaults

[conner-lotus]

I have a handful of bash scripts that utilize the defaults write command to change various .plist values and modify preferences. I've seen them work before using each of the login and privileged login locations within Outset, but I can't recreate those results. The logs all say that the scripts are processing with no issues, including my own logs that are echoed from within the script, but for some reason the defaults command refuses to write to the .plists. Also, this only happens when processing it through Outset. If I run the command by itself, or if I run the script from Terminal, the defaults command executes properly and the .plists are modified.

My first thought is that maybe Outset needs to be given some permissions, but all the scripts have root ownership and mode 755, and it usually says in the logs when it doesn't have permission to do something somewhere, sometimes even by line number. Also, this occurs with both standard and admin accounts.

Is Outset perhaps only executing these as the root user, and as a result not writing to the user-specific .plist files?

[conner-lotus]

Also worth noting: I am using the -currentHost option with the defaults command. The way I understand it, this applies changes to .plists per host by instead changing the .plist files in the ByHost folder within Preferences, to be applied at a level different from the way you would by simply changing the user's individual .plist files directly.

[chilcote]

As a guess, I'd suggest that maybe defaults commands don't work correctly when run in a launchd context.

Easy enough to test that hypothesis. Create a launchagent independent of outset that does a defaults write to some domain, and let that trigger when you log in, and see if it works.

[kevinmcox]

For what it's worth I run defaults commands with Outset including one with a --currentHost option: https://github.com/kevinmcox/outset-scripts/blob/main/usr/local/outset/login-once/FinderSettings.sh

[jaydisc]

Is it possible the commands that are failing are defaults writes to com.apple.mail, or com.apple.safari, or any other app that has protected folders in Security & Privacy?

[kevinmcox]

Jay, the location of the Safari and Mail preferences changed in Big Sur: https://github.com/kevinmcox/outset-scripts/blob/main/usr/local/outset/login-once/SafariSettings.sh

[jaydisc]

Are the new preference locations similarly protected by Security & Privacy?

Update: Just had a check and writing to files there is still forbidden without the proper Privacy permission.

I thought when you just specify the identifier (com.apple.mail), and not the full path, you can rely on the OS to locate it. As long as I have Full Disk Access in Security & Privacy, these two commands provide identical output:

defaults read com.apple.mail

defaults read ~/Library/Containers/com.apple.mail/Data/Library/Preferences/com.apple.mail.plist

Without Full Disk Access, both fail (falsely stating the domains do not exist).

[kevinmcox]

Yep, looks like you are correct. Safari and Mail have been real hit-or-miss in my testing and this explains it.

For Safari in particular, even under Catalina, once the app had been opened by a user the script wouldn't work. So it has always been flaky.

We've switched to Chrome and Gmail as the default here so I haven't spent much time on this. Since you are in the MacAdmins Slack it might be easier to continue the discussion / troubleshooting there.