Problem with LaunchAgent in Sierra - "Ignore ownership" flag did not seem to work

Recently upgraded from El Capitan to Sierra, and the problem with LaunchAgent not running returned.

Disk layout is the same as I had last time I had this problem - I’ve just upgraded to bigger drives: SpamSieve still not working with Yosemite - SpamSieveLaunchAgent not running.

“Ignore Ownership” proved to be on, so I turned it off, and that let me install the plugin in Apple Mail.

However, even after successfully adding the plugin to Apple Mail, and even after numerous reboots, Console tells me “SpamSieve Mail Plug-In: SpamSieveLaunchAgent is not running. It may be necessary to choose “Install Apple Mail Plug-In” from the SpamSieve menu or to restart your Mac.”.

Manually running the LaunchAgent gave me this message:

launchctl load ~/Library/LaunchAgents/com.c-command.SpamSieve.LaunchAgent.plist
/Volumes/Data/Users/per/Library/LaunchAgents/com.c-command.SpamSieve.LaunchAgent.plist: Path had bad ownership/permissions

What’s missing this time?

What does this Terminal command show?

ls -lea ~/Library/LaunchAgents/

I get:

total 80
drwxr-xr-x   7 <accountname>  staff   238 Jul 25 02:03 .
drwxr-xr-x+ 72 <accountname>  staff  2448 Jul 25 19:13 ..

Then 128 lines for the numbers 0 to 127 like:

0: group:everyone deny delete
...
127: group:everyone deny delete

before these files at the bottom:

-rw-r--r--   1 <accountname>  staff   697 Mar  5  2016 com.adobe.AAM.Updater-1.0.plist
-rw-r--r--   1 <accountname>  staff   733 Mar 26 11:48 com.c-command.SpamSieve.LaunchAgent.plist
-rw-r--r--   1 <accountname>  staff   696 Jul 13 22:44 com.dropbox.DropboxMacUpdate.agent.plist
-rw-r--r--   1 <accountname>  staff   543 May 21 22:01 com.propaganda.dejavu.dvmonitor.plist
-rw-r--r--   1 <accountname>  staff  1095 Jul 27 16:56 com.valvesoftware.steamclean.plist

That looks OK to me, and the permissions are the same as for your other launch agents. Are those having problems as well?

It might help to delete the com.c-command.SpamSieve.LaunchAgent.plist file so that SpamSieve creates a new one.

Another possibility is that there’s a problem with the permissions on the SpamSieve launch agent itself (SpamSieve.app/Contents/Frameworks/SpamSieveFramework.framework/Resources/SpamSieveLaunchAgent), which is referenced by the plist.

I deleted the com.c-command…plist file, started SpamSieve, installed the Apple plugin again (don’t know if that was needed), saw the plist-file had been recreated, and now it works.

It’s so easy to forget these “Ignore ownership” checkboxes whenever initializing new drives. It doesn’t help that they seem to be default on. (I guess it makes sense having this setting on when moving drives between computers where the user account in question isn’t always the same User ID, but besides that it seems to me like it’s never really needed.)

Could future versions of SpamSieve possibly decide to recreate the plist-file under certain circumstances?

It seems that it was all that was needed in addition to manually clearing “Ignore ownership”. If I get this correctly, the ownership flag prevented the plugin from being installed, but the plist-file needed to be recreated in order for the launch agent to actually run.

Permissions for the launch agent itself has probably been OK all this time:

7694974 -rwxr-xr-x   1 administrator  admin  140960 Feb 27 17:51 SpamSieveLaunchAgent

It’s needed because that’s what tells SpamSieve to install the launch agent, which isn’t needed if you aren’t using Apple Mail.

It already tries to fix the permissions/ownership if they are wrong and saves the plist if it detects that it’s different than would be saved. So in theory deleting the file, as you did, wouldn’t have any effect. If you do:

ls -lea ~/Library/LaunchAgents/

does it look different from before (other than the date)? I would be really curious to know what changed after it saved the new file.

With the wrong ownership flag, SpamSieve reports an error installing the launch agent plist because it knows that the system won’t load it until the ownership is fixed. SpamSieve is just trying to get you to fix that checkbox.

I don’t know why recreating the plist was necessary for it to actually run, since SpamSieve had previously decided that the new plist would be identical to the old one.

The permissions and the file size for the plist-file are identical - Had I thought about it, I’d moved the file and not deleted it, so I could compare the contents. Unfortunately, I don’t use Time Machine at present, so the old file is gone.