LaunchServices: Could not store lsd-identifiers file at /private/var/db/lsd/com.apple.lsdschemes.plist

Probably not the best way, but I seem to have fixed/suppressed that error message. This is what I did:

cd /private/var/db

lsd directory did not exist

mkdir lsd

Still no joy

chmod -R 777 /private/var/db/lsd

(i know, i just opened up my gibson to being hacked)

touch /private/var/db/lsd/com.apple.lsdschemes.plist

Seemed to go away after that. Willing to bet a disk repair/permissions check will break it again, but have not tried. If I cat that file the following is the content:

bplist00?

In my case a repairing of the fs permissions made the file appear.

The lsd dir has "root wheel rwxr_xr_x" ownership/permissions.

See one of my earlier posts.

I still have the error. The file has the same content as yours.

he only difference is that my MB starts twice as fast and is more responsive.

This solved the problem for me, but I believe it may be only patching the symptom itself. If you look in Activity Monitor, you'll probably see multiple instances of lsd running, one under root and at least one under your own user. I believe the console error was a result of the one running under your own user not having permissions to write to /private/var/db/lsd, and changing the permissions to be world-writeable fixed that. What I can't figure out without another instance of El Capitan running is whether it's normal or not for lsd to run as a user that's not root.

Had the same problem with a lot of messages. The only thing I've done, is quit the two processes in AktivityMonitor. They restart by their own, give a message that the missing file is created an everything went normal.

No lsd-directory is needed and it don't exist in my system.

same issue too, did not have the folder even after creating the folder a still get errors

did not understand if only this solve

sudo /usr/libexec/repair_packages --repair --standard-pkgs --volume /

or 777 permission

)

)

I'm getting the exact same messages on a 13-inch mid-2011 macbook air. 4GB of RAM. It appears to be heating up the machine to a level I've never seen before (I'm afraid to leave the machine running for any extended period due to the heat). Can't bring myself to upgrade my macbook pro to El Capitan until I know there's some way to work through this issue (that sticks). Any and all information will be greatly appreciated.

After struggling with this for longer than reasonable before realizing it was a red herring entirely unrelated to my actual issue (which, unfortunately, I would strongly suggest is the case for everyone), I'm posting the comprehensive collection of steps necessary to fully resolve this. All of the responses so far contain partial solutions with assumptions about existing permissions, being logged in as root, rebooting afterwards, etc. The below solution is less invasive than doing Linc's full ownership/permissions resets, as suggested by a couple replies.

INSTRUCTIONS

Run ALL of the commands below, even if you think they're redundant to steps you've previously taken -- and especially since there may be other permissions issues at play. None of them are destructive.

Create the folder

sudo mkdir /private/var/db/lsd

Create the file

sudo touch /private/var/db/lsd/com.apple.lsdschemes.plist

Set ownership

Note: It should already be set to this if created by the above command, but running this command ensures that if the file or folder already existed (or if you have weird group assignments), the ownership is corrected.

sudo chown -R root:wheel /private/var/db/lsd

Set permissions

Warning: While unlikely, this could potentially allow someone to achieve escalated permissions on your device, but only if they've already hacked into a user account... at which point, you're probably already screwed.

sudo chmod -R 777 /private/var/db/lsd

Set extended attributes (optional?)

Note: Probably unnecessary, but also totally harmless. And if you want to be sure it matches what others have reported from working installs...

xattr -wr com.apple.finder.copy.source.checksum#N 4 /private/var/db/lsd

xattr -wr com.apple.metadata:_kTimeMachineNewestSnapshot 50 /private/var/db/lsd

xattr -wr com.apple.metadata:_kTimeMachineOldestSnapshot 50 /private/var/db/lsd

Restart Launch Services Dameon

Note: This is something unmentioned in other posts and can cause a lot of grief in troubleshooting. If things were significantly messed up to start with, the service needs to be restarted in order for the change to be picked up by the process.

sudo killall -9 lsd

Wait up to 60 seconds for the service to restart

(Final note: lsd is NOT Little Snitch Daemon. The similarities in naming are a coincidence. Don't try to uninstall or disable lsd.)

Here is the little solution-script...

Have a look - hope that helps !

#!/bin/bash

# First we repair the Apple-Stuff..

sudo /usr/libexec/repair_packages --repair --standard-pkgs --volume /

# Second we want not so much errors in the logs...

sudo mkdir /private/var/db/lsd

sudo touch /private/var/db/lsd/com.apple.lsdschemes.plist

sudo chown -R root:wheel /private/var/db/lsd

sudo chmod 775 /private/var/db/lsd

sudo chmod 664 /private/var/db/lsd/com.apple.lsdschemes.plist

sudo xattr -wr com.apple.finder.copy.source.checksum#N 4 /private/var/db/lsd

sudo xattr -wr com.apple.metadata:_kTimeMachineNewestSnapshot 50 /private/var/db/lsd

sudo xattr -wr com.apple.metadata:_kTimeMachineOldestSnapshot 50 /private/var/db/lsd

sudo killall -9 lsd

# ready

Your sudo mkdir of the lsd dir saved me from this issue. Thanks!

Do not do the above!!!

1. The numbers after an extended attribute name in output from an 'ls'command are the size of the attributes in bytes, not the value of the attributes. Setting the attributes to those numbers is worthless at best.
2. A file's extended attributes and ACL inside a Time Machine backup are not the same as the original live file. Specifically it records in those 3 extended attributes:
   • A checksum of the file contents, as a guard against backup corruption.
   • The timestamps of the first and last snapshots in which a file appears (in binary plist format), so it can swiftly figure out where to find all of the links to the file if you use "Delete All Backups Of This File" in Time Machine.

Setting those extended attributes is not necessary or even useful and could in fact be harmful. Those attributes are all set and used by Time Machine, and the values they are set to by the suggested commands are nothing like what Time Machine might set them to, but rather are the sizes in bytes of the attributes as set by Time Machine: a 4-byte CRC-32 checksum and 2 timestamps wrapped in binary plist structures.

Setting those could be harmful because it is not clear what Time Machine does when a live file has existing extended attributes of the same names as those it uses internally. At best, it will simply discard what is on the live file but it is conceivable that it will throw an error and skip the file or even that it will backup the file with those attributes and fail to add its own with the correct contents that it needs to work with the backup properly.

Hi,

I was facing the same issue. My lsd process was trying to rebuild the missing /private/var/db/lsd/com.apple.lsdschemes.plist but it failed for some reason :

lsd[356]: LaunchServices: Scheme mapping file does not exist, creating file.

ReportCrash[354]: Saved crash report for lsd[355] version 728.13 to /Library/Logs/DiagnosticReports/lsd_2016-09-13-110239_backup.crash

ReportCrash[354]: Removing excessive log: file:///Library/Logs/DiagnosticReports/lsd_2016-09-13-110146_backup.crash

diagnosticd[123]: error evaluating process info - pid: 356, puniqueid: 356

com.apple.xpc.launchd[1] (com.apple.lsd[356]): Service exited due to signal: Segmentation fault: 11

lsd[357]: LaunchServices: Scheme mapping file does not exist, creating file.

ReportCrash[354]: Saved crash report for lsd[356] version 728.13 to /Library/Logs/DiagnosticReports/lsd_2016-09-13-110242_backup.crash

ReportCrash[354]: Removing excessive log: file:///Library/Logs/DiagnosticReports/lsd_2016-09-13-110149_backup.crash

As you can see, the lsd process kept crashing. None of the previous suggestions worked for me.

After a while I decided to check the output of lsof. As root, in a Terminal, I ran :

$ lsof | grep lsd

I found that lsd was using a file (amongst others) called /private/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/0/com.apple.LaunchService s-1340.csstore . This one caught my attention.

Still as root, I moved this file away, thinking "maybe it's corrupt" :

$ cd /private/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/0/

$ mv ./com.apple.LaunchServices-1340.csstore ./com.apple.LaunchServices-1340.csstore.bak

Then I rebooted. And the file was recreated. And then lsd could create the missing /private/var/db/lsd/com.apple.lsdschemes.plist file. And my issue was gone 🙂

Hope that can help someone !

Thank you!

This has solved the issue.

After making the folder, do this and see if this doesn't fix the error...

chmod -R 777 /private/var/db/lsd

touch /private/var/db/lsd/com.apple.lsdschemes.plist