Skip navigation

HT5338: How to convert a local user account to a network user account

Learn about How to convert a local user account to a network user account

HT5338 After conversion, error found in logs

687 Views 4 Replies Latest reply: Dec 4, 2012 4:38 PM by d.carpenter RSS
d.carpenter Calculating status...
Currently Being Moderated
Dec 4, 2012 11:58 AM

I use JAMF's Casper Suite to manage our company's Macs. In this suite there is an application called Self Service that allows users to choose what they want to download from our company's store. After a user has been migrated using these steps, we see this show in the application's log after trying to install something:

 

Error loading /System/Library/Security/ldapdl.bundle/Contents/MacOS/ldapdl: dlopen(/System/Library/Security/ldapdl.bundle/Contents/MacOS/ldapdl, 262): no suitable image found.  Did find:

/System/Library/Security/ldapdl.bundle/Contents/MacOS/ldapdl: mach-o, but wrong architecture

 

This is causing the Self Service app to report to the user that their installation failed, eventhough it actually did install successfully. I suspect that it may be caused by the UID changing from a standard 3 digit to a directory based 10 digit number, but I'm not sure. I've verified that the network user is the owner of their home folder (we keep their home folders local, not on the server).

 

Does anyone have any thoughts on something to try?

MacBook Pro, OS X Mountain Lion (10.8.2)
  • MrHoffman Level 6 Level 6 (11,695 points)
    Currently Being Moderated
    Dec 4, 2012 2:04 PM (in response to d.carpenter)

    If you're on the current version, contact JAMF for assistance.  If you're not on the current version of JAMF, consider an update.  As a guess, they may have some code that's expecting 32-bit.  But in any case, their code has something that's either a bug or an incompatibility.

  • MrHoffman Level 6 Level 6 (11,695 points)
    Currently Being Moderated
    Dec 4, 2012 4:32 PM (in response to d.carpenter)

    I've seen cases where code was expecting 32-bit or 64-bit executable, and got handed a binary with only 64-bit or 32-bit build, and that triggered an architecture error.

     

    The following will tell you how the tool was built...

     

    file {filename}

    otool -hV -arch all {filename}

     

    Based on a quick check of a local Mountain Lion box, that file is built as 64-bit, so the caller should be (needs to be) expecting a 64-bit build.

     

    I don't know of an easy way to see what the caller is expecting, short of rummaging around inside that executable.

     

    (This stuff is pretty obvious, so I'd expect the support folks would have thought of this already...)

Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)

Legend

  • This solved my question - 10 points
  • This helped me - 5 points
This site contains user submitted content, comments and opinions and is for informational purposes only. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.