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

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.)

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 !

That's not coming from Little Snitch. The filename starts with com.apple.*, that means it's a system service/daemon. Most probably it's the Launch Service Daemon (lsd). My systems have never seen Little Snitch and I have the same issue.

I've just created the folder lsd with the command "sudo mkdir /private/var/db/lsd" and did a reboot. I got just one new message in Console saying "lsd: LaunchServices: Scheme mapping file does not exist, creating file." and that's it. No new error messages after that.

I made the xattr changes and it did not appear to work. The "Could not store lsd-identifiers file" messages continued appearing every 10 minutes or whenever Spotlight tried to update an index.

Then, I found this Apple Support Discussion thread where Linc Davis suggested a solution to a different problem (Installing Safari Extensions) that was producing the exact same error messages I have been seeing in Console. The solution is Linc's standard command-line script used to "unlock all your user files (not system files) and reset their ownership, permissions, and access controls to the default."

https://discussions.apple.com/thread/7275606?start=0&tstart=0

I tried it and It appears to have worked!! The error messages we have been experiencing have re-appeared only once since I applied Linc's solution. The "Could not store lsd-identifiers file" message has only appeared once in an hour and it seems to have been generated after a FolderActionsDispatcher process. I think this an totally unrelated issue. Before I applied Linc's solutions, I was seeing 1,000s of occurrences of the "Could not store lsd-identifiers file" message an hour.

Give it a try and see if it fixes your problem.

Thanks, Linc!

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.

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

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.

I have the same problem and I think I know what the issue is preventing it from being solved. I noticed that manfredall has marked his question as solved (calling it a OS X bug), but I believe I know why creating a new folder does not fully fix the problem and I need some help to implement the fix correctly.

When I created a new lsd directory and allowed the system to rebuild the com.apple.lsdschemes.plist file after a reboot, the "Could not store lsd-identifiers file" messages continued. Then, I looked at the same directory and file on a recent, Time Machine backup of this El Capitan (Mac OS X 10.11.1) system and I noticed both the directory and the file had extended () file permission attributes. These extended attributes are not automatically assigned when a new lsd directory is created and must be written to the com.apple.lsdschemes.plist file's attributes using the xattr command.

Here is the list of the extended attributes attached to the file from the backup of this El Capitan system (immediately after updating from Yosemite):

MacBook-Air:lsd user$ ls -l@ *

-rw-r--r--@ 2 root wheel 42 Oct 29 12:01 com.apple.lsdschemes.plist

com.apple.finder.copy.source.checksum#N 4

com.apple.metadata:_kTimeMachineNewestSnapshot 50

com.apple.metadata:_kTimeMachineOldestSnapshot 50

I strongly believe that if we assign the same extended attributes to the com.apple.lsdschemes.plist file inside the new lsd directory that we created, we will at least partially resolve this issue by restoring the LaunchServices process' ability to write to this file.

I know I need to use the xattr command, but I am not comfortable enough with my rusty UNIX skills to create the proper command. Can anyone help? Here is my first attempt at structuring the necessary commands:

xattr -w com.apple.finder.copy.source.checksum#N 4 com.apple.lsdschemes.plist

xattr -w com.apple.metadata:_kTimeMachineNewestSnapshot 50com.apple.lsdschemes.plist

xattr -w com.apple.metadata:_kTimeMachineOldestSnapshot 50com.apple.lsdschemes.plist

Do these look correct?

FWIW - Background (of how I got into trouble): Yesterday, during a Time Machine backup of a MacBook Air, I noticed the backupd process appeared to have stop/slowed approximately two-thirds of the way through the backup. When I looked at the Console log, I saw that various Spotlight processes were in a major "battle" with LaunchServices attempting to resolve a problem with the LaunchServices database. At this point, I decided to rebuild that database using the commonly used (since at least 2003) command:

/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.fra​mework/Support/lsregister -kill -r -domain local -domain system -domain user

I immediately realized that not only did this command not fix the problem, I started seeing a large number of Console messages that suggested I had made the problem worse.

10/29/15 11:35:42.685 AM lsd[253]: LaunchServices: Could not store lsd-identifiers file at /private/var/db/lsd/com.apple.lsdschemes.plist

Next, I decided to rebuild the LaunchServices database using the El Capitan (3.1.1) version of Onyx. That created the same problem and I had to manually recreate the lsd directory again.

Obviously, the method of rebuilding the LaunchService database has changed in El Capitan (Mac OS X 10.11.1) and has not been properly revised in Onyx 3.1.1 to be fully compatible and compliant. Thus, I would strongly recommend against using Onyx 3.1.1 to rebuild any OS X files until these types of issues have been fully flushed out.

Having this problem to.

Created the directory, the file is not created.

Did a repair on file permissions: sudo /usr/libexec/repair_packages --repair --standard-pkgs --volume /

Now this old MB boots up twice as fast.

Some messages from the repair:

User differs on "private/var/db/displaypolicyd", should be 0, user is 244.

Group differs on "private/var/db/displaypolicyd", should be 0, group is 244.

Repaired "private/var/db/displaypolicyd".

Permissions differ on "private/var/root", should be drwxr-x--- , they are drwxr-xr-x .

Repaired "private/var/root".

Permissions differ on "private/var/root/Library", should be drwx------ , they are drwxr-xr-x .

Repaired "private/var/root/Library".

Permissions differ on "usr/libexec/cups/cgi-bin", should be drwxr-xr-x , they are dr-xr-xr-x .

Repaired "usr/libexec/cups/cgi-bin".

Permissions differ on "usr/libexec/cups/daemon", should be drwxr-xr-x , they are dr-xr-xr-x .

Repaired "usr/libexec/cups/daemon".

Permissions differ on "usr/libexec/cups/driver", should be drwxr-xr-x , they are dr-xr-xr-x .

Repaired "usr/libexec/cups/driver".

Permissions differ on "usr/libexec/cups/monitor", should be drwxr-xr-x , they are dr-xr-xr-x .

Repaired "usr/libexec/cups/monitor".

Permissions differ on "usr/libexec/cups/notifier", should be drwxr-xr-x , they are dr-xr-xr-x .

Repaired "usr/libexec/cups/notifier".

unfortually the error is stil in the logs

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?

Hi all,

you should only create the directory /lsd with root user.

After a while I've seen the file com.apple.lsdschemes.plist created.

MacBook-Pro:~ root# cd /private/var/db/

MacBook-Pro:db root# mkdir lsd

MacBook-Pro:db root# ls -la lsd/

total 0

drwxr-xr-x 2 root wheel 68 Oct 25 01:31 .

drwxr-xr-x 71 root wheel 2414 Oct 25 01:31 ..

MacBook-Pro:db root# cd lsd

MacBook-Pro:lsd root# ls -lart

total 8

drwxr-xr-x 71 root wheel 2414 Oct 25 01:31 ..

-rw-r--r-- 1 root wheel 42 Oct 25 01:32 com.apple.lsdschemes.plist

drwxr-xr-x 3 root wheel 102 Oct 25 01:32

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.

Hi manfredell,

you're right. I've seen that some app uses the file correctly and some other no.

In my system I've found some of those messages but the last time used is after the messages. Probably we're facing a permission problem.

Try to live the file as is and check last update time ad messages, probably you will find the same situation. I'm trying to give permission also to wheel group not only to root user.

This will not help if there is a service that tries to write the file but from other users/groups than root:wheel

as you can see we have two lsd services so this is the problem.

last message:

25/10/15 05:54:58,250 lsd[590]: LaunchServices: Could not store lsd-identifiers file at /private/var/db/lsd/com.apple.lsdschemes.plist

file status

MacBook-Pro:lsd root# ls -lart

total 8

drwxr-xr-x 73 root wheel 2482 Oct 25 03:52 ..

-rw-r--r-- 1 root wheel 42 Oct 25 09:42 com.apple.lsdschemes.plist

drwxr-xr-x 3 root wheel 102 Oct 25 09:42 .

MacBook-Pro:lsd root#

I've also seen the console messages. I also had the missing directory, and simply creating the directory didn't resolve the issue. They all started appearing after the upgrade to El Capitan.

In addition, I recently had a bout of problems with the "lsd" process running at very high CPU load. It was running at (what Activity Monitor showed as) 100% of CPU (which, on a multi-core system, was about 1/2 the CPU capacity). While this problem existed on my system, I could not perform various Finder actions - such as moving new applications into the /Applications folder, or Empty Trash. In addition, my 3rd-party backup app (CrashPlan) was also running at very high CPU (even though configured not to).

I believe my underlying issue was that Launch Services was trying to accomplish something on behalf of Finder in each case, and something was causing lsd to get into a race condition. (An examination of the stacktraces from spindump of the lsd process (via Activity Monitor) looked suspiciously like a multithreaded race condition.)

My problems, and the directory issue in this thread, seem related. I went through a barrage of calls with Apple Support (and they, too, made the mistake of thinking this was "little snitch daemon", when in fact a stacktrace shows it to be the OS X Launch Services; fortunately, they accepted my digging.) But they never did figure it out *really*. In the end, they sent me towards the step of doing a full hard drive reformat, and fully fresh OS re-install.

Interestingly, in the process of deleting vast quantities of files from my primary (built-in) drive in preparing for the re-install (after having moved them to a 2TB external drive), the LSD process (and CrashPlan) high-CPU load problems magically disappeared, and have stayed away even though I've restored many of the files that had been transferred to external drive.

I note that I also have a troubling number of OS crashes in the last 6 months. And they aren't even the kind of kernel panic that causes the OS to trigger the dialog to send a dump to Apple. My Mac just crashes, and I have to hit the power button to start it, and it simply boots again - no admission of guilt. ;-) I don't know if the crashes are related to lsd; I bet not. BUT, the reliability of OS X has definitely declined in recent years.

I definitely think there is some new issue in El Capitan relative to lsd - the launch services daemon in OS X. I hope we can raise this to Apple's OS X core engineering - though I have no idea how.