Just upgraded to SpamSieve 2.9.19, and then Mac OS X 10.10.2.
Still, SpamSieve is unable to work properly.
Whenever I try to use “Train as Good” or “Train as Spam”, nothing happens beside a beach ball, and this shows in the console:
28.01.15 01.03.46,371 Mail[1325]: SpamSieve Mail Plug-In: SpamSieveHelper does not seem to be running. Trying to launch it.
28.01.15 01.03.46,372 Mail[1325]: 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.
28.01.15 01.03.46,372 Mail[1325]: SpamSieve Mail Plug-In: Launching via launch agent failed.
Never had one single problem with SpamSieve before Yosemite, but after upgrading my computers, the SpamSieveLaunchAgent has not worked.
Launching SpamSieve on its own, generates this line in the console:
28.01.15 01.06.13,523 com.apple.xpc.launchd[1]: (com.apple.xpc.launchd.user.501.100005.Aqua) Caller specified a plist with bad ownership/permissions: path = /Volumes/Data/Users/gmc/Library/LaunchAgents/com.c-command.SpamSieve.LaunchAgent.plist, caller = launchctl.4250
These are the current persmissions for this plist-file:
The exact same error happens when I try “Install Apple Mail Plugin”.
23951586 -rw-r–r-- 1 gmc staff 602 Jan 28 01:08 com.c-command.SpamSieve.LaunchAgent.plist
I Have have external home folder ever since the first days of Mac OS X.
In the beginning, I merely pointed my user to the external volume, but since that was hit-and-miss due to the amount of time various volumes needed to mount,
I have for several years used a symbolic link instead, in the /Users folder.
SpamSieve has never given me one single problem before Yosemite.
Refining my query in Google to “SpamSieveLaunchAgent is not running”, I get two hits, one of which is:
(The other hit being indirect, as part of a Spotlight-related log-dump in an Apple forum).
This person has in fact the exact same problem as I have - He hasn’t inspected the log when he installs, but otherwise it’s the same behaviour.
This must be Yosemite-related, otherwise there would have been the odd problem popping up before late 2014.
I think that problem may be solved because he said “Looks like it took” and I never heard from him again. In any case, it is interesting that he also seems to have his home folder on an external drive.
That one doesn’t seem to be the same problem as yours. It’s just the relatively normal error that the helper app is not running. There is no error from launchd, so it probably fixed itself upon reboot.
Could be. What were the last versions of SpamSieve and Mac OS X where it was working for you? I don’t think any of SpamSieve’s launch agent code changed in 2.9.19.
Did you try restarting your Mac?
Incidentally, the permissions you had looked fine to me. This is what launctl says they should be. Although this page suggests that maybe the group should be “wheel”. On my Mac, it’s “admin”. Do you have any other launch agents in that folder that work? If so, what do their ownership and permissions look like?
I have updated SpamSieve twice after upgrading to Yosemite - so the last version that worked was “two versions before the current one” - can’t remember more precisely.
All OS version up to and including Mountain Lion worked - My current computer went through a clean install of Yosemite (skipped Mavericks). Behaviour is the same on another Mac, where I upgraded from Mountain Lion to Yosemite.
I’ve had multiple restarts and software updates since Yosemite got installed, and SpamSieve behaves in the same way - Training doesn’t work.
My LaunchAgents folder contains:
12673178 -rw-r–r-- 1 gmc staff 697 Oct 8 2013 com.adobe.AAM.Updater-1.0.plist
24059219 -rw-r–r-- 1 gmc staff 602 Feb 1 21:37 com.c-command.SpamSieve.LaunchAgent.plist
13341786 -rw-r–r-- 1 gmc staff 543 Oct 31 2013 com.propaganda.dejavu.dvmonitor.plist
24033733 -rw-r–r-- 1 gmc staff 819 Feb 1 14:27 com.valvesoftware.steamclean.plist
12673183 -rw-r–r-- 1 gmc staff 677 Oct 16 2013 org.virtualbox.vboxwebsrv.plist
I have not noticed any problems with Adobe, DéjàVu, Steam or Virtualbox - have as such not studied the system logs at length.
My Data volume (as well as all other non-system partitions) has the default setting of “Ignore ownership” - Is that a potential problem?
Yes. I would suggest trying it without “Ignore ownership.”
By the way, a launch agent is just a plist file. It doesn’t have any code. So you can test it when SpamSieve is not running by entering this command in Terminal:
Ok - Tried the command in terminal, got the same response:
/Volumes/Data/Users/gmc/Library/LaunchAgents/com.c-command.SpamSieve.LaunchAgent.plist: Path had bad ownership/permissions
This is without changing the “Ignore ownership” property.
Since this is not a volume with OS on it, there is no obvious way I can “repair permissions” on it - so I’m unsure if turning “Ignore” off will have any immediate effect.
I’m not sure whether it will help, but it will definitely have an effect. When “ignore” is off, the system will be able to see the actual permissions for that file, and SpamSieve will be able to fix them if necessary.
Finally got around to actually turning off the “ignore ownership” flag, and SpamSieve worked right away. No log entries, messages just moved when I did Cmd+Ctrl+S.
This detail should be present in some FAQ - “If your user folder is on a remote/separate volume, remember to turn off “Ignore ownership””.
This is what worked for me too … but i’m a bit worried that turning off ‘ignore ownership’ might cause problems. Is there no need to worry about turning it off?
But my user is on an extern TB RAID array, and so i’m a bit worried that un-checking ‘ignore ownership’ will give me problems down the line … would this be right, or should i not worry?
Thanks for the follow-up. It makes sense that launchd would not want to run a launch agent with unknown ownership.
As far as I know, this hasn’t come up before. I will definitely add it to the manual, and hopefully there will also be a way that SpamSieve can check for this during installation.
It should be safe to turn it off. That is the normal way that Mac OS X operates. For example, it is always off for the boot volume. The main reason that you would want to ignore owners is if you bring your external hard disk to another Mac and that Mac wants to access files that are owned by you.