54

I have a Launch Agent configured to run a .plist file for example: /Library/LaunchAgent/foo.plist. Inside this .plist, it is set to run during LoginWindow and Aqua.

When I attempt to launch my computer and get to the login screen, this plist should run but instead gives the following error (in the console):

launchctl: Dubious ownership on file (skipping): /Library/LaunchAgents/foo.plist

When I attempt to login in to a non-admin account, it gives the exact same error message. When I attempt to login with an admin account, it works fine.

I'll be honest, I don't know much about Mac OS X privileges and permissions.

To create the file, I opened it up in emacs, with sudo on the admin account (e.g. by using the su command since the other account doesn't have sudo privileges) and then saved it.

Which account do I need to use to create the file so that it works for all users?
Do I need to use the sudo command?
Do I need to change the file permissions (e.g. use chmod)?
Is there an easy way to take an existing file and change its ownership instead of having to recreate the file?
Could someone please explain why this error happens?

Improve this question
3
  • What does ls -l give for /Library/LaunchAgent/foo.plist
    – mmmmmm
    Oct 18, 2010 at 7:46
  • 1
    @Mark: it gives the following: -rw-r--r--@ 1 admin staff 653 Oct 17 14:31 /Library/LaunchAgents/foo.plist
    – Senseful
    Oct 18, 2010 at 18:01
  • It's also possible to force the loading (-F).
    – kenorb
    May 21, 2015 at 14:04

5 Answers 5

Reset to default
51

If a plist is owned by root and writable by a user other than root, that's a security issue.

You can change the owner to root with sudo chown root <filename>, and change the permissions with sudo chmod 644 <filename> (4 for read access, 2 for write access, 1 for execute access, added up. The first number is for the owner, the second for the group, the third for everyone.)

Improve this answer
4
  • This works. I'm just confused as to why I had to change the owner to root though. Is root the user that is used for LaunchAgents?
    – Senseful
    Oct 18, 2010 at 20:57
  • 1
    Yes, I think so.
    – Michiel de Mare
    Oct 18, 2010 at 21:08
  • 1
    I know this is an older post, but this is a great answer! I changed the permissions on /system/library/launchdaemons/com.apple.mdnsresponder to try a fix that Apple recommended, but I would get the error mentioned above when trying to load it afterwards. Changing the owner and permissions as described above was the only way to get my internet connection back. Thanks!
    – user6243
    May 4, 2011 at 21:48
  • Faced the same now and solved. I figured that the owner of the file much invoke launchctl. I created the file as my normal user and was executing with sudo. Hence the error. Because root is not the owner of the file, No sudo was not needed. I ran without sudo and it worked fine.
    – Bibhas
    May 1, 2013 at 4:45
14

From the launchctl(1) manpage’s description of the load subcommand:

Note that per-user configuration files (LaunchAgents) must be owned by the user loading them. All system-wide daemons (LaunchDaemons) must be owned by root. Configuration files must not be group- or world-writable. These restrictions are in place for security reasons, as allowing writability to a launchd configuration file allows one to specify which executable will be launched.

launchctl has several “Dubious …” messages. The launchd code for 10.6.7 (for example) has three such messages in its launchctl.c (see the function path_goodness_check).

  1. Dubious permissions on file (skipping): <pathname>
  2. Dubious ownership on file (skipping): <pathname>
  3. Dubious path. Not a regular file or directory (skipping): <pathname>

To avoid these messages a pathname must be (#3) a regular file or directory1 (or a symlink to one) that is (#1) owned by root or the invoking user and (#2) not “group” or “other” writable (i.e. chmod go-w).

1 No named pipes, block/character special device nodes, local domain sockets, etc.

Your file is probably owned by the admin user since you say that you do not get the message when logging in as that user (the pathname is owned by the invoking user in that case).
To make the pathname work for other users, it should be owned by root.

To arrange this, do:

sudo chown root /Library/LaunchAgent/foo.plist
Improve this answer
1

Thanks for the answer (changing owner to root) -- that's all I needed.

To make this a bit more than a 'me too' post... I got here via a convoluted path: I was getting "This API can only be used by a process running within an Aqua session" errors for a launchdaemon. Searching for an answer to that led me to Apple's technote on daemons and agents which explained how to resolve the 'Aqua session' error, but that left me with 'dubious ownership' issues. That's how I got here, where my final issue was resolved.

Maybe adding all of that to this discussion will cause some search engine to link this page to one of the precursory issues, thereby saving some future adventurer some time.

Improve this answer
2
  • Note, this should be a comment rather than an answer.
    – studgeek
    Feb 22, 2015 at 18:59
  • 1
    I would have commented, but my reputation points were not high enough. (Doesn't it seem backwards that one can 'answer' with a low reputation but not comment?)
    – Matt Strange
    Jun 8, 2015 at 18:32
-2

for file in ~/Library/LaunchAgent owned by the user and not root dont sudo, if you do youll have to change the ownership since you are loading it from the root user

Improve this answer
-3

This is what happens when people do not know how sudo works. To disable services that are on files owned by your user just call launchtl without sudo.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .