manfredell

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

I get a lot of those entries in the console:  lsd[364]: LaunchServices: Could not store lsd-identifiers file at /private/var/db/lsd/com.apple.lsdschemes.plist

 

I have updated to El Cap from Mavericks. I have checked the disk with DiskUtility and DiskWarrior. All OK.

 

Checking this folder /private/var/db/lsd/ I found that it didn't exist. Created.


The file com.apple.lsdschemes.plist was created in this folder but I still get those messages in the Console!?

MacBook Air (13-inch, Early 2014), OS X El Capitan (10.11)

Posted on Oct 8, 2015 2:20 AM

Close

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

  • All replies
  • Helpful answers

Previous Page 2 of 3 last Next
  • by Mitch Str,

    Mitch Str Mitch Str Oct 30, 2015 9:41 AM in response to manfredell
    Level 1 (0 points)
    Oct 30, 2015 9:41 AM in response to manfredell

    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 50 com.apple.lsdschemes.plist


    xattr -w com.apple.metadata:_kTimeMachineOldestSnapshot 50 com.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.

  • by Mitch Str,

    Mitch Str Mitch Str Oct 30, 2015 10:25 AM in response to Mitch Str
    Level 1 (0 points)
    Oct 30, 2015 10:25 AM in response to Mitch Str

    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

  • by manfredell,

    manfredell manfredell Oct 30, 2015 10:30 AM in response to Mitch Str
    Level 1 (8 points)
    Mac OS X
    Oct 30, 2015 10:30 AM in response to Mitch Str

    Yes I think you are correct here. Onyx, El Cap Cache Cleaner etc cause more trouble when rebuliding launch services, exactly as you describe. It is definitely a permission problem somehow.

     

    I have executed your commands with SUDO in front. Let's see what happens.

  • by Mitch Str,

    Mitch Str Mitch Str Oct 30, 2015 12:01 PM in response to manfredell
    Level 1 (0 points)
    Oct 30, 2015 12:01 PM in response to manfredell

    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!

  • by manfredell,

    manfredell manfredell Oct 30, 2015 12:38 PM in response to Mitch Str
    Level 1 (8 points)
    Mac OS X
    Oct 30, 2015 12:38 PM in response to Mitch Str

    Did that. Still getting those messages......

  • by Mitch Str,

    Mitch Str Mitch Str Oct 30, 2015 4:38 PM in response to manfredell
    Level 1 (0 points)
    Oct 30, 2015 4:38 PM in response to manfredell

    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?

  • by manfredell,

    manfredell manfredell Oct 31, 2015 3:22 AM in response to Mitch Str
    Level 1 (8 points)
    Mac OS X
    Oct 31, 2015 3:22 AM in response to Mitch Str

    Yes I applied both solutions.

     

    After 12hrs of doing it I get one of those notifications per hour.

  • by MikezMac,

    MikezMac MikezMac Nov 8, 2015 6:31 AM in response to manfredell
    Level 1 (24 points)
    iPhone
    Nov 8, 2015 6:31 AM in response to manfredell

    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$

  • by halfjapanese,

    halfjapanese halfjapanese Nov 9, 2015 12:46 PM in response to manfredell
    Level 1 (0 points)
    Nov 9, 2015 12:46 PM in response to manfredell

    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.

  • by ylluminate,

    ylluminate ylluminate Nov 14, 2015 9:22 AM in response to halfjapanese
    Level 1 (10 points)
    Nov 14, 2015 9:22 AM in response to halfjapanese

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

  • by Jay Batson,

    Jay Batson Jay Batson Nov 28, 2015 7:03 AM in response to manfredell
    Level 1 (0 points)
    Nov 28, 2015 7:03 AM in response to manfredell

    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.

  • by avdheuvel,

    avdheuvel avdheuvel Nov 30, 2015 2:17 PM in response to manfredell
    Level 1 (0 points)
    Nov 30, 2015 2:17 PM in response to manfredell

    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

  • by LawHusick,

    LawHusick LawHusick Dec 8, 2015 1:58 PM in response to manfredell
    Level 1 (0 points)
    Dec 8, 2015 1:58 PM in response to manfredell

    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

  • by vfC,

    vfC vfC Dec 12, 2015 6:35 AM in response to LawHusick
    Level 1 (4 points)
    Dec 12, 2015 6:35 AM in response to LawHusick

    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?

  • by avdheuvel,

    avdheuvel avdheuvel Dec 12, 2015 8:27 AM in response to vfC
    Level 1 (0 points)
    Dec 12, 2015 8:27 AM in response to vfC

    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.

Previous Page 2 of 3 last Next