26

I wanted to remove applications from location services in the security and privacy settings on MaC OS X 10.8 Mountain Lion. (The apps were still listed even though they were uninstalled.) I found the post Remove application from Location Services in Security & Privacy on Mac OS X 10.7, and that got me going in the right direction. Here is the OS X 10.8.2 Mountain Lion equivalent that worked for me. The main difference is the location of the clients.plist file. I also wanted to provide a step-by-step process.

DISCLAIMER: This worked for me. Make sure you have a good backup of your system. This process includes making a backup of the clients.plist file, but one can never be too safe.

1. Start terminal and then sudo to a root shell
sudo -s

2. Go to /var/db/locationd
cd /var/db/locationd

3. Make a backup of the clients.plist file
cp -p clients.plist clients.plist.save

4. Convert clients.plist to xml (editable format)
plutil -convert xml1 clients.plist

5. Use vi (vim) to edit the clients.plist file and remove the application.
vi clients.plist

The file will likely contain many application entries. Here is the format of a single application entry (Safari in this case). The entire entry needs to be deleted.

    <key>com.apple.Safari</key>
    <dict>
        <key>Authorized</key>
        <true/>
        <key>BundleId</key>
        <string>com.apple.Safari</string>
        <key>Executable</key>
        <string>/Applications/Safari.app/Contents/MacOS/Safari</string>
        <key>LocationTimeStopped</key>
        <real>376348187.80421197</real>
        <key>Registered</key>
        <string>/Applications/Safari.app/Contents/MacOS/Safari</string>
        <key>RequirementString</key>
        <string>identifier "com.apple.Safari" and anchor apple</string>
        <key>Whitelisted</key>
        <false/>
    </dict>

6. Convert the clients.plist file back to binary
plutil -convert binary1 clients.plist

7. Restart locationd
killall locationd

If the apps are still there, do the process again, except restart locationd using kill -9 after determining the PID as follows. The PID is the second field in the ps output.

ps -ef | grep locationd | grep -v grep
Output: 205 427 1 0 6:31PM ?? 0:00.07 /usr/libexec/locationd
kill -9 427

I ran the process twice to remove one app at a time. The first time, killall was sufficient. The second time, it was not. I do not know why. It acted like locationd was keeping a cache and rebuilding clients.plist. I say this because the entries were added back to clients.plist after running killall -- and even on a reboot. Whatever the root cause, using kill -9 solved the problem for me.

If things go badly, then copy back the original file and restart locationd.
cp -p clients.plist.save clients.plist
killall locationd (or the kill -9 method)

I hope this helps. Cheers!

3
  • 1
    kill -HUP might be more reliable; it's the legacy kill signal to tell a daemon to flush its cache and re-read its config file. I see that killall -HUP locationd would work. A possible reason the other kills didn't work might be the cache files were left to be read by the newly spawned process. Apr 12, 2013 at 23:40
  • Fun fact: I'm not sure whether this behavior existed before High Sierra, but at least in this macOS if you uncheck a file that no longer exists in the preferences pane, usually the app will no longer display it in the list. However, using this method, I discovered that several of these supposedly deleted apps were, in fact, still in the list, just not displayed.
    – DonielF
    Jan 14, 2018 at 17:47
  • I should also note, based on my experience with this: I tried using this to remove an Applescript of mine from System Preferences, for reasons, and it kept popping up that it wanted my location for several attempts until it finally shut up. I assume this is because I kept trying to run that line of code in the Applescript, and the bash kept running in the background until it was deleted from my System Preferences...and thus it went on to the next line in the bash. Since I had multiple of these running in the background, apparently, I had to cancel each one individually while doing this.
    – DonielF
    Jan 14, 2018 at 19:21

5 Answers 5

6

Xcode's property list editor can also be used to delete old apps' entries, but since the file is hard to get to, permissions have to be temporarily opened:

mini-nevie:~ root# chmod o+rwx /var/db/locationd/ /var/db/locationd/clients.plist

so the directory and file can be read and written by all users. Then, for convenience, su to your login ID:

mini-nevie:~ root# su - nevinwilliams
mini-nevie:~ nevinwilliams$ open /var/db/locationd/clients.plist 

This assumes Xcode is the default app for opening *.plist files, and you're familiar with the Property List Editor. Under the Root property, there are 3 default Dictionary entries:

com.appl
com.appl.locationd.executable-/usr/libexec/UserEventAgent
com.appl.aosnotifyd

Those ought not to be removed. For entries that belong to long-gone apps, you can hover just to the left of the Dictionary column of the corresponding app's row, where an inverse grey '-' will appear. Clicking on it will remove the item, and all its children. If you'd rather inspect the entry first, clicking on the grey triangle (familiar to Finder list-view users) to the left of the key string will expand the Dictionary and display its elements.

Once you delete or disable the keys to your satisfaction, save the file, and quit Xcode. Then, back in Terminal, do:

mini-nevie:~ nevinwilliams$ exit
logout
mini-nevie:~ root# 

hit the up-arrow twice to recall the chmod command, ctrl-A to go to the beginning of the line, cursor-right about eight times, change the '+' to a '-', or enter the following as shown to restore permissions to what they were:

mini-nevie:~ root# chmod o-rwx /var/db/locationd /var/db/locationd/clients.plist 

then HUP the location daemon:

 mini-nevie:~ root# killall -HUP locationd

a quick check of the Security.PrefPane Privacy tab ought to confirm your changes.

Standard disclaimers, cautionary tales of woe, scoldings, cluckings, and "Is This Trip Really Necessary?" reflections are especially applicable.

4

Using tccutil (OS X Command Line utility)

I think the fastest and safest way to do this, is by the OS X command line utility tccutil

  • Open a new terminal window
  • Close any open "Security & Privacy" prefpane windows
  • Type or paste from the following highlighted commands

Reset the Location services

tccutil reset CoreLocationAgent

Reset access to contacts/address book:

tccutil reset AddressBook

Reset access to Reminders

tccutil reset Reminders

Reset access to Calendars

tccutil reset Calendar

And that´s all there is to it. No Sudo needed, by the way.

5
  • Not working for me unfortunately. I get a Failed to reset database message. Feb 6, 2018 at 11:07
  • @strangetimes: I had totally forgotten about this. I have not tried the modified tccutil mentioned in this link, but it seems to me like it's worth a shot: github.com/jacobsalmela/tccutil
    – Andreas
    Feb 8, 2018 at 19:14
  • @strangetimes : I forgot to mention that the reason it's not working, is due to the system integrity protection, according to github.com/jacobsalmela/tccutil
    – Andreas
    Feb 8, 2018 at 19:20
  • 1
    The command tccutil reset CoreLocationAgent does not seem to work anymore. See this issue.
    – Ryan
    Sep 28, 2018 at 16:46
  • It worked for me to remove the calendars but is not working to request a new authorization. To do that i had to remove the user/library/calendar/calendar cache database then restart the computer Nov 29, 2018 at 6:46
3

This is the old one and the solution I propose isn't technically different from the solution in the post and accepted one, but it's much less hassle and much easier to automate (useful for debugging). Just do

/usr/libexec/PlistBuddy -c 'Delete <bundle-id>' /var/db/locationd/clients.plist
killall -HUP locationd

as root.

4
  • Didn't work for me on macOS 10.15.7 - while PlistBuddy doesn't report an error, the record is still there. And now things are even more funny - while item is not displayed in the GUI, it is still in the plist. Dec 7, 2020 at 14:14
  • @NickolayOlshevsky, indeed, doesn't seem to work anymore. Interestingly, after running the command, timestamp of the plist is not updated. And touch reports "Operation not permitted". I think it has to do with the new macos system integrity protection thingie or some other newer security feature… Dec 7, 2020 at 19:42
  • Looks like a root is not a real root anymore. Dec 8, 2020 at 20:49
  • @NickolayOlshevsky, yes, not what it used to be… There's still an option to turn integrity protection off, I believe, but I wouldn't bother. Dec 9, 2020 at 6:20
1

Remove Application from Location Services in Security & Privacy by right clicking on the app entry to go to the app folder. Close Security & Privacy.

Terminal command:

  1. sudo chown -R [your Mac id] /var/db/locationd (change ownership temporarily to you)
  2. plutil -convert xml1 /var/db/locationd/clients.plist (convert the binary plist to text-based plist in XML format)
  3. vi /var/db/locationd/clients.plist (Edit clients.plist) arrow key to move to the starting line and use "dd" command to erase one line. Move down the lines until the key-dict pair of your app entry is removed
  4. Restart Mac

P.S.: There is no need to change the ownership back to you or convert the plist file back to binary format. It will be reset to default ownership or format very soon by the OS.

0

In addition to previous answers, this problem only went away for me after correcting file ownership:

# chown -R _locationd:_locationd /var/db/locationd/
# chmod 750 /var/db/locationd/
# chmod 644 /var/db/locationd/clients.plist

Then restart the computer.

You must log in to answer this question.

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