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

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.

Last info.

This daemon is an Apple one, not Little Snitch (as some forums says).

So can't be deleted or uninstalled.

Definitely it's a OS X bug!

ciao

p

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.

Here are improved versions of the commands I am attempting to build correctly. The change assigns the extended attribute to the lsd directory and recursively to any file written to the directory.

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

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!

I performed both solutions. I applied the extended attributes to the lsd directory and ran Linc's permission repair script. Lina's script does not repair system files, including the lad directory.

Did you try applying both?

I have this problem as well.

iMac:db mikezmac$ pwd

/private/var/db

iMac:db mikezmac$ ls -l lsd

ls: lsd: No such file or directory

iMac:db mikezmac$ ls -la lsd

ls: lsd: No such file or directory

iMac:db mikezmac$

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

I saw the same error in my console and following your lead, I created the lsd folder to make the errors go away.

Thank you.

I found this post very interesting. After looking at three OS X machines, none of them have the `/private/var/db/lsd`.

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.

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

I have now tried every suggested fix for this:

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

None of them work. OS X 10.11.2, iMac 5K