Users not disconnected from file sharing

It's not a server problem, it is a client problem.

It happens with Mavericks server 3.1.2, Snow Leopard Server and Windows Server 2012.

I'm seeing this problem from a Lion client as well. I don't think it is limited to Mavericks clients.

[Solved]

For me at least, unless I'm being premature.

sudo serveradmin settings afp:clientSleepOnOff = No

After making this change it started working properly.

So far I've on my home server I've done 10 consecutive backups without the problem reoccurring. It now disconnects from afp aprox 1 minute after finishing backing up.

And thinking about it, there are lots and lots of people posting with sleep problems.

I've also made a few change to afp settings without changing them back to default so it is possible it is a combination of those settings. And you know that adage," if it ain't broke don't fix it", i'm not feeling brave enough to try changing those settings back. It works and that's all I care about.

All changes I've made:

afp:reconnectTTLInMin = 20

afp:idleDisconnectTime = 1

afp:idleDisconnectOnOff = yes

afp:clientSleepOnOff = no

afp:clientSleepTime = 3

afp:maxGuests = 0

afp:idleDisconnectFlag: registeredUsers = yes

Server 3.1.2

all machines running OS X 10.9.3

Ok, so maybe I was a little premature, it only solved half my problem, the part with Time Machine, but doesn't always disconnect users when I pull the network cable.

I too am finding that the Mavericks client will not let go of network home mounts (AFP mounts) after a user logs off. I am beginning to think that the reason for this is because of rouge processes that will not die after the user has logged out.

For those interested in trouble shooting .... this is how I gathered the evidence:

1. Log in to a Mavericks client as the local administrator
2. Switch user and log into the same client as a network user
3. Start a few apps ... Mail, Addressbook ... these application create locks on files in the ~/Library directory.
4. Log out of the network user.
5. Switch user back to the local administrator
6. Run the "df" in a terminal window. You will see the network user home directory still mounted.
7. Run the following "umount" command in a terminal window, you will notice it returns a device busy error
   umount /Network/Servers/fred.frank.com/Users/fredumount(/Network/Servers/fred.frank.com/Users/fred): Resource busy -- try 'diskutil unmount
8. Open the "Activity Monitor" application, then click "View / All Processes". Sort by user name. You will notice several processes still running that are owned by the network user who has logged out.
9. I killed all these processes, but the Users AFP share remains mounted. I suspect there are also processes that are owned by service users such "_postgres" that are also left over from the network user's session.

All this makes you think a client reboot will fix it. But not always ... the server still seems to hang onto connections and hold open locked files sometimes. A server reboot ... I presume that will clear it ... I haven't tested that enough to prove for sure. We can't reboot our server all the time. Besides, clients need to be resilient enough to let the average user log in and out more than once in their lifetime.

This problem actually causes a series of other problems reported on these discussion boards. For example:

1. AddressBook Beachballs
   If AddressBook has its cache file open (~Library/Spplication Support/AddressBook/Sources/GUID/AddressBook-v22.adcdd), then this remains locked. On a subsequent login by a user, the addressbook hangs, waiting for the lock to release. Addressbook is used by the autofill features in Safari, Mail, Spotlight, Calendar etc. So this then causes a ripple effect to all those applications whenever the user types anything that looks anything like a contact name, that subsequent application hangs. I had users with spinning beachballs on all these apps, where the only solution is to power cycle the machine, then log into the server app and disconnect their sessions.
   If you open a terminal window and try to look at (ls -lsa) of the ~Library/Application Support/AddressBook/Sources/GUID/AddressBook-v22.adcdd ... there is a good chance you will get the good old ".afpDeleted: No such file or directory" error. Also pointing to a file that is deleted, but not entirely until a stale process finally quits and releases a file lock.
   This is particularly a problem with users who have connections to MS-Exchange accounts (such as office 365 accounts). Addressbook cache seems to be modified a locked a lot more regularly for these accounts.
2. Repeatedly Forgotten Passwords and System Preferences Hanging
   This also reaks havot with Key Chain, Profile Manager and all of the System Preferences panes ... many of these settings are kept in the ~Library folder ... which also contain locked file from stale processes of a previous login. A typical symtom being user passwords for Mail acconts are not remembered because the keychain store file is locked. I've seen entire prefrence panes freeze/not load at all because of this problem. For example, the user clicks on the "iCloud" or "Internet Accounts" option, the title bar changes to "Loading iCloud Settings...." but the pane never loads. I also see profiles fail to load/unload properly. I've seen profile unload, but the associated preference settings not change (e.g. a mail account might get deleteed, but the associated address book account remain because a file was locked). The only option here is to force quit and reboot the client and then clear the client connection in the File Sharing service pane of the Server app.

Worst of all, its unpredictable. Depending what processes the user was running in their previous login session, depends on what files are locked, which in turn affects what applications are affected on subsequent login sessions. Because of the way it ripples unpredictibly through every application on the Mac (all of which rely on the ~/Library folder), it makes a iMac feel like a Vista machine ... hanging, unpredictable, unreliable. Our users have lost a lot of faith in the Macs as a result.

Hope this helps others troubleshoot a soluton. This is hurting our business. Every user in our business is a network user, and this defect has stopped most network accounts from working.

Client = Mavericks 10.9.3

Server = Mavericks 10.9.3

@Peteeee,

Thanks for the extensive testing. It sounds like you're seeing some additional behavior (both 1 and 2) with your system that mimics problems I am having that I have never been able to fully solve. I've been wondering if they are all related?

In summary:

• I have problems with AFP connections not ending. I also have a user on Lion who has problems with being disconnect while trying to work. In fact, the AFP connection remains according the server, but he cannot work. Basically need to clear ~/Library/Caches and have him log in again.
• On a MacMini 10.9.3, a different user seems to have the home directory get confused and a reboot is requried to get it back. Okay, not a real technical description but that is because I haven't figued a good one out yet. Essentially the behavior you described above with addressbook is what we experience. If the user remains logged in for extended periods and the workstation goes to sleep. Or, if someone else logs in, then the workstation needs to be rebooted. Unfortunately, this seems to be getting worse (most recent update?)
• Kerberos with Mail (hosted on a second server) was so unrealiable I disabled it.

When I set this system up a few months back I rebuilt both servers and workstations several times. Never could get this stuff to work right. But you're the first person I've seen with both the AFP and the addressbook/password problems. We may be able to help each other?

Are you using home directories shared over AFP? I tried a couple days ago so shift to SMB but that didn't work. Today I'm configured with both AFP and SMB turned on, home sharing is set to go over SMB, but in reality only AFP connections are made. I susepct I need to clear all the file sharing settings and try again. But now I'd like to hear your config first if you don't mind?

Tim

p.s., I started wondering if my router might be the issue? Linksys E4200 SOHO.

Hey Tim,

I think we could have the same problems. So far, the root cause has not been found , but here's where I am at:

• Problem 1: Adressbook beach balls, forgotten passwords, apps hanging, system preferences hanging. It is unpredictible which apps are affected. Sometimes all of them. Sometimes only some of them.
• Problem 1 is caused by Problem 2: AFP network homes are not fully released (umounted) on log out.
• Problem 2 is caused by Problem 3: When a user logs out, not all processes are terminated. This leaves files locked and prevents the AFP network home from being released. When the user next logs in, the apps cannot access all the users settings & files, because they are still locked. The desktop becomes unstable. This explains why problem 1 is not predictible - because what files are locked depends on what apps the user was running in the earlier login session.
• Problem 3 is caused by ????: I can't explain why yet. This is my focus. A fundamental rule of unix/macosx is that when a user logs out, all the "foreground processes" (apps and stuff) they are running are terminated. I just can't yet grasp how Macosx could be leaving processes running after a log out. I guess I will start by looking at the client and server logs.

I've been wondering if they are all related?

I beleive they all are indeed related - as I outlined above. Macs will always become very unreliable if the user's Library folder cannot be reliably accessed by the user. What could cause the user's folder to not be reliably accessed? Examples I've thought of are as follows (and also shows whether I've eliminated these on my site):

For Local Users & Network Users:

Incorrect permissions on the user's folders (eliminated)

For Network Users:

1. Unreliable network connection (eliminated)
2. Incorrect DNS configuration (eliminated)
3. Incorrect File Sharing Configuration (eliminated)
4. Incorrect Open Directory configuration / users and groups setting wrong (eliminated)
5. Lock files caused by stale AFP connections (suspected)
6. Locked files caused by the user logging into two machines on the network at the same time (eliminated)
7. Fast switching between two network users on the same machine ... this changes the AFP mount to be owned by another user, causing the original user to loose write access to their files (eliminated)

These can all cause all the desktop problems .... addressbook beachballs, forgotten passwords, key chains error, system preferences.

On a MacMini 10.9.3, a different user seems to have the home directory get confused and a reboot is requried to get it back. Okay, not a real technical description but that is because I haven't figued a good one out yet.

That could happen if you are fast switching between two network users on the same machine.

When I set this system up a few months back I rebuilt both servers and workstations several times. Never could get this stuff to work right. But you're the first person I've seen with both the AFP and the addressbook/password problems. We may be able to help each other?

Are you using home directories shared over AFP? I tried a couple days ago so shift to SMB but that didn't work. Today I'm configured with both AFP and SMB turned on, home sharing is set to go over SMB, but in reality only AFP connections are made. I susepct I need to clear all the file sharing settings and try again. But now I'd like to hear your config first if you don't mind?

I can confirm I am using home directories shared over AFP. That is what I mean when I refer to "Network Users" above. I can also confirm both server and the client are Mavericks 10.9.3. I can also confirm they are abolutely vanilla installs, following Apple recommended settings. The user I am testing is always a brand new user, with a brand new user home directory. I always create a brand new user before starting my testing.

I have also proven that everything works fine when the user firsts logs in for the first time - ever. After that, anything can happen. The computer sleeps and reawakes, or the user logs out and back in, then all the problems start. Then user's experience on other client computers can be affected if the Library directory gets corrupted by this problem.

The most convincing test I have done is as follows:

1. Local User - setup a local user on a Maverick 10.9.3 client.
2. Network User - on another client, I setup a network user again, a Maverick 10.9.3 client.
3. Both users are identical - same mail accounts, same email address, same login name, same iclould account, same key chain settings, same profiles, same everything. The only difference is that the local user's home directory is not on the server and therefore does not use AFP.

The local user has been running problem free for 1 month. The network user does not last one day.

Like you, I began to question everything about my network. Router, DNS, file sharing ... but I could not find anything. No packet errors, good ping times, excellent DNS resolution, ability to access and write to file shares .... everything was perfect.

Looks like AFP and unterminated processes are close to the root cause ... and it is looking more and more like an Mavericks defect rather than a configuration issue. But until I get to the bottom of it, I can't be sure.

Hope this helps.

Pete.

Problem 3 is caused by ????: I can't explain why yet. This is my focus. A fundamental rule of unix/macosx is that when a user logs out, all the "foreground processes" (apps and stuff) they are running are terminated. I just can't yet grasp how Macosx could be leaving processes running after a log out. I guess I will start by looking at the client and server logs.

I've been wondering if they are all related?

I came here trying to track down a similar problem. I wonder if it's not related to the "Power Nap" feature? That allows a machine to check for mail, do Time Machine backups etc. I wonder if having that enabled means some of these processes aren't dying off properly.

Enable Power Nap

While sleeping, your Mac can back up using Time Machine and periodically check for new email, calendar, and other iCloud updates.

It has a setting for both while on battery and while plugged in. I wonder if disabling that on all client machines will cause the number of bad connections to plummet.

This morning my server showed 10,000+ connected users, out of 50 actual. I'm going to go through and try disabling this setting, see if it makes these various Time Machine shares etc. drop properly.

I should note, I'm experiencing the multitude of login problems/ghost shares, and these are NOT networked users. These are just accounts to use network services, and the accounts have local home directories.

Pete,

Thank you for the extensive reply. I'll try to hit some of the points with my experiences.

For your problem 2, I've noticed something that may be related. I would create users when I was testing several months ago so I would have fresh configurations. What I noticed was that the temporary files on the client do not get cleaned up when I would delete the user. I'm not even sure this was occuring when the workstation was rebooted, but I am not positive about this. I do know that the new user I would create would sometimes get confused on the UID. Not sure if this was a server side issue because the server would reuse UIDs (short version, not GUID/UUID).

Rather than using fast switching, have you tried to ssh into the workstation after the regular user has logged out and then look at processes running?

I also have to add that some of the behavior you describe as problem 1, I've seen in ML with a ML server too. If you were to search for my other posts, you could read some of this drama. I've at times thought the problems were related to database migrations (originally for SLS). If you never migrated wiki/addressbook/calendar data to the system you're testing now, that will help me rule that out. But if you have migrated data, we may want to leave that possibility on the table.

Regarding network users, by using the phrase home directories shared over AFP, I'm differentiating it to portable home directories where they are synchronized between the server and the client. I now have another laptop and will be experimenting with that to see if I experience problems.

I will try again (but not sure when) to drive my network to SMB vice AFP and see if there is any improvement.

Tim

esmithmpp,

I do not have power nap enabled and the issues I have are not solely occuring when the computer has gone into a power save mode. However, because there is similarity in that proceses are running in the background, I could not rule out a relationship between our problems.

That said, I do not experience the creation of excessive connections (10k?!?). I think you're right to focus on TM.

Tim

Pete,

I experience another issue that I believe may be related to how Apple AFP is working between the client and the server. The computer that is using networked home directories cannot handle quicklook of vCards. If a vCard is place on the desktop (or a folder) and the quicklook process acceses, meltdown of the user's version (i.e., the local/cached copy in the user's directory) contact data occurs. Then a reboot is requried and the user has to redownload the contact data from the server. Serveral Addressbook-v22.abcddb.UUID.unknown* files are left stale in the ~/Library/Application Support/Addressbook directory.

This problem does not occur on the two Macbooks that are using PHDs. On those, Quicklook of vCards properly works.

Attached below is the log of the meltdown:

6/6/14 7:25:43.908 PM Console[1866]: setPresentationOptions called with NSApplicationPresentationFullScreen when there is no visible fullscreen window; this call will be ignored.
6/6/14 7:26:36.880 PM com.apple.quicklook.satellite[1869]: CoreData: error: (3) access permission denied
6/6/14 7:26:36.907 PM com.apple.quicklook.satellite[1869]: Unknown error reading database file, will attempt reimporting: Error Domain=NSCocoaErrorDomain Code=256 "The file couldn’t be opened." UserInfo=0x7f8ff2d31b30 {NSSQLiteErrorDomain=3, NSUnderlyingException=error during execution of SQL string 'pragma journal_mode=wal' : access permission denied} {
    NSSQLiteErrorDomain = 3;
    NSUnderlyingException = "error during execution of SQL string 'pragma journal_mode=wal' : access permission denied";
}
6/6/14 7:26:36.908 PM com.apple.quicklook.satellite[1869]: Move Address Book store at /Network/Servers/server.domain.com/path/to/user/Library/Application Support/AddressBook/Sources/UUID1/AddressBook-v22.abcddb to /Network/Servers/server.domain.com/path/to/user/Library/Application Support/AddressBook/Sources/UUID1/AddressBook-v22.abcddb.FBBF74DA-12E1-4E46-B2B9-E989548181C6.unknown
6/6/14 7:26:36.944 PM com.apple.quicklook.satellite[1869]: Could not replace store at file:///Network/Servers/server.domain.com/path/to/user/Library/Application%20Support/AddressBook/Sources/UUID1/AddressBook-v22.abcddb.FBBF74DA-12E1-4E46-B2B9-E989548181C6.unknown from file:///Network/Servers/server.domain.com/path/to/user/Library/Application%20Support/AddressBook/Sources/UUID1/AddressBook-v22.abcddb: Error Domain=NSSQLiteErrorDomain Code=3 "The operation couldn’t be completed. (NSSQLiteErrorDomain error 3.)" UserInfo=0x7f8ff2c22100 {NSFilePath=/Network/Servers/server.domain.com/path/to/user/Library/Application Support/AddressBook/Sources/UUID1/AddressBook-v22.abcddb.FBBF74DA-12E1-4E46-B2B9-E989548181C6.unknown, reason=Failed to replace destination database} {
    NSFilePath = "/Network/Servers/server.domain.com/path/to/user/Library/Application Support/AddressBook/Sources/UUID1/AddressBook-v22.abcddb.FBBF74DA-12E1-4E46-B2B9-E989548181C6.unknown";
    reason = "Failed to replace destination database";
}
6/6/14 7:26:37.038 PM com.apple.quicklook.satellite[1869]: CoreData: error: (3) access permission denied
6/6/14 7:26:37.042 PM com.apple.quicklook.satellite[1869]: 0x7f8ff2d21930: ManagedObjectContext (ABAddressBook) could not create the store at path: </Network/Servers/server.domain.com/path/to/user/Library/Application Support/AddressBook/Sources/UUID1/AddressBook-v22.abcddb> - creation error: Error Domain=NSCocoaErrorDomain Code=256 "The file couldn’t be opened." UserInfo=0x7f8ff2d34cd0 {NSSQLiteErrorDomain=3, NSUnderlyingException=error during prepareSQL for SQL string 'pragma auto_vacuum=2' : access permission denied} {
    NSSQLiteErrorDomain = 3;
    NSUnderlyingException = "error during prepareSQL for SQL string 'pragma auto_vacuum=2' : access permission denied";
}
6/6/14 7:26:37.050 PM com.apple.quicklook.satellite[1869]: CoreData: error: (3) access permission denied
6/6/14 7:26:37.051 PM com.apple.quicklook.satellite[1869]: Unknown error reading database file, will attempt reimporting: Error Domain=NSCocoaErrorDomain Code=256 "The file couldn’t be opened." UserInfo=0x7f8ff2c4ce40 {NSSQLiteErrorDomain=3, NSUnderlyingException=error during execution of SQL string 'pragma journal_mode=wal' : access permission denied} {
    NSSQLiteErrorDomain = 3;
    NSUnderlyingException = "error during execution of SQL string 'pragma journal_mode=wal' : access permission denied";
}
6/6/14 7:26:37.051 PM com.apple.quicklook.satellite[1869]: Move Address Book store at /Network/Servers/server.domain.com/path/to/user/Library/Application Support/AddressBook/Sources/UUID2/AddressBook-v22.abcddb to /Network/Servers/server.domain.com/path/to/user/Library/Application Support/AddressBook/Sources/UUID2/AddressBook-v22.abcddb.AC297050-C515-4B94-A061-E176BBC19591.unknown
6/6/14 7:26:37.111 PM com.apple.quicklook.satellite[1869]: Could not replace store at file:///Network/Servers/server.domain.com/path/to/user/Library/Application%20Support/AddressBook/Sources/UUID2/AddressBook-v22.abcddb.AC297050-C515-4B94-A061-E176BBC19591.unknown from file:///Network/Servers/server.domain.com/path/to/user/Library/Application%20Support/AddressBook/Sources/UUID2/AddressBook-v22.abcddb: Error Domain=NSSQLiteErrorDomain Code=3 "The operation couldn’t be completed. (NSSQLiteErrorDomain error 3.)" UserInfo=0x7f8ff2d5a1d0 {NSFilePath=/Network/Servers/server.domain.com/path/to/user/Library/Application Support/AddressBook/Sources/UUID2/AddressBook-v22.abcddb.AC297050-C515-4B94-A061-E176BBC19591.unknown, reason=Failed to replace destination database} {
    NSFilePath = "/Network/Servers/server.domain.com/path/to/user/Library/Application Support/AddressBook/Sources/UUID2/AddressBook-v22.abcddb.AC297050-C515-4B94-A061-E176BBC19591.unknown";
    reason = "Failed to replace destination database";
}
6/6/14 7:26:37.346 PM com.apple.quicklook.satellite[1869]: CoreData: error: (3) access permission denied
6/6/14 7:26:37.349 PM com.apple.quicklook.satellite[1869]: 0x7f8ff2d21930: ManagedObjectContext (ABAddressBook) could not create the store at path: </Network/Servers/server.domain.com/path/to/user/Library/Application Support/AddressBook/Sources/UUID2/AddressBook-v22.abcddb> - creation error: Error Domain=NSCocoaErrorDomain Code=256 "The file couldn’t be opened." UserInfo=0x7f8ff2c5d740 {NSSQLiteErrorDomain=3, NSUnderlyingException=error during prepareSQL for SQL string 'pragma auto_vacuum=2' : access permission denied} {
    NSSQLiteErrorDomain = 3;
    NSUnderlyingException = "error during prepareSQL for SQL string 'pragma auto_vacuum=2' : access permission denied";
}
6/6/14 7:26:37.358 PM com.apple.quicklook.satellite[1869]: CoreData: error: (3) access permission denied
6/6/14 7:26:37.359 PM com.apple.quicklook.satellite[1869]: Unknown error reading database file, will attempt reimporting: Error Domain=NSCocoaErrorDomain Code=256 "The file couldn’t be opened." UserInfo=0x7f8ff2e52ed0 {NSSQLiteErrorDomain=3, NSUnderlyingException=error during execution of SQL string 'pragma journal_mode=wal' : access permission denied} {
    NSSQLiteErrorDomain = 3;
    NSUnderlyingException = "error during execution of SQL string 'pragma journal_mode=wal' : access permission denied";
}
6/6/14 7:26:37.360 PM com.apple.quicklook.satellite[1869]: Move Address Book store at /Network/Servers/server.domain.com/path/to/user/Library/Application Support/AddressBook/AddressBook-v22.abcddb to /Network/Servers/server.domain.com/path/to/user/Library/Application Support/AddressBook/AddressBook-v22.abcddb.9D2C7CBC-9968-456D-BDB2-6723CE3F3305.unknown
6/6/14 7:26:37.418 PM com.apple.quicklook.satellite[1869]: Could not replace store at file:///Network/Servers/server.domain.com/path/to/user/Library/Application%20Support/AddressBook/AddressBook-v22.abcddb.9D2C7CBC-9968-456D-BDB2-6723CE3F3305.unknown from file:///Network/Servers/server.domain.com/path/to/user/Library/Application%20Support/AddressBook/AddressBook-v22.abcddb: Error Domain=NSSQLiteErrorDomain Code=3 "The operation couldn’t be completed. (NSSQLiteErrorDomain error 3.)" UserInfo=0x7f8ff2e3f0a0 {NSFilePath=/Network/Servers/server.domain.com/path/to/user/Library/Application Support/AddressBook/AddressBook-v22.abcddb.9D2C7CBC-9968-456D-BDB2-6723CE3F3305.unknown, reason=Failed to replace destination database} {
    NSFilePath = "/Network/Servers/server.domain.com/path/to/user/Library/Application Support/AddressBook/AddressBook-v22.abcddb.9D2C7CBC-9968-456D-BDB2-6723CE3F3305.unknown";
    reason = "Failed to replace destination database";
}
6/6/14 7:26:37.524 PM com.apple.quicklook.satellite[1869]: CoreData: error: (3) access permission denied
6/6/14 7:26:37.528 PM com.apple.quicklook.satellite[1869]: 0x7f8ff2d21930: ManagedObjectContext (ABAddressBook) could not create the store at path: </Network/Servers/server.domain.com/path/to/user/Library/Application Support/AddressBook/AddressBook-v22.abcddb> - creation error: Error Domain=NSCocoaErrorDomain Code=256 "The file couldn’t be opened." UserInfo=0x7f8ff2d65aa0 {NSSQLiteErrorDomain=3, NSUnderlyingException=error during prepareSQL for SQL string 'pragma auto_vacuum=2' : access permission denied} {
    NSSQLiteErrorDomain = 3;
    NSUnderlyingException = "error during prepareSQL for SQL string 'pragma auto_vacuum=2' : access permission denied";
}
6/6/14 7:26:37.559 PM com.apple.quicklook.satellite[1869]: *** attempt to post distributed notification 'ABWillRestoreFromMetadataPriv' thwarted by sandboxing.


Date/Time:     Fri Jun  6 19:26:37 2014
OS Version:    13D65
Application:   com.apple.quicklook.satellite


Backtrace:
0   CoreFoundation                      0x00007fff8df18312 __CFGenerateReport + 242
1   CoreFoundation                      0x00007fff8dd8b102 _CFXNotificationPost + 882
2   Foundation                          0x00007fff91421804 -[NSDistributedNotificationCenter postNotificationName:object:userInfo:options:] + 73
3   AddressBook                         0x00007fff97bb790f -[ABAddressBook nts_RestoreFromMetaDataIfNeededAndTriggerSync:] + 209
4   AddressBook                         0x00007fff97b21ca9 -[ABAddressBook nts_RestoreFromMetaDataIfNeeded] + 22
5   AddressBook                         0x00007fff97b21c39 -[ABAddressBook nts_DoInitialImports] + 157
6   AddressBook                         0x00007fff97b1e13f ABRunWithLock + 166
7   AddressBook                         0x00007fff97b1b994 +[ABAddressBook nts_SharedAddressBook] + 129
8   AddressBook                         0x00007fff97b1b86e +[ABAddressBook nts_CreateSharedAddressBook] + 49
9   AddressBook                         0x00007fff97b1b6e1 +[ABAddressBook sharedAddressBook] + 69
10  AddressBook                         0x00007fff97b1b5f7 +[ABAddressBook addressBookWithDatabaseDirectory:options:] + 56
11  AddressBook                         0x00007fff97b8b36a +[ABAddressBook(ABAddressBookHackery) emptyMemoryBackedAddressBookWithOptions:] + 39
12  AddressBook                         0x00007fff97c230fe +[ABAddressBook(ABAddressBookHackery) provisionalMemoryBackedAddressBook] + 106
13  AddressBook                         0x00007fff97beb106 -[ABVCardParser people] + 41
14  Contact                             0x000000010880269c Contact + 9884
15  QuickLook                           0x00007fff8b2dbe23 _QLThumbnailRequestCallGenerator + 585
16  QuickLookSatellite                  0x0000000107d75249 main + 6233
17  QuickLookSatellite                  0x0000000107d766aa _QLUUIDForRequest + 150
18  QuickLookSatellite                  0x0000000107d74fa4 main + 5556
19  QuickLook                           0x00007fff8b30c181 _Z18QLTryCatchAndCrashU13block_pointerFvvE + 17
20  libdispatch.dylib                   0x00007fff93f0e1bb _dispatch_call_block_and_release + 12
21  libdispatch.dylib                   0x00007fff93f0b28d _dispatch_client_callout + 8
22  libdispatch.dylib                   0x00007fff93f0d673 _dispatch_queue_drain + 451
23  libdispatch.dylib                   0x00007fff93f0e9c1 _dispatch_queue_invoke + 110
24  libdispatch.dylib                   0x00007fff93f0cf87 _dispatch_root_queue_drain + 75
25  libdispatch.dylib                   0x00007fff93f0e177 _dispatch_worker_thread2 + 40
26  libsystem_pthread.dylib             0x00007fff93154ef8 _pthread_wqthread + 314
27  libsystem_pthread.dylib             0x00007fff93157fb9 start_wqthread + 13
6/6/14 7:26:37.573 PM com.apple.quicklook.satellite[1869]: Restoring DB from MetaData
6/6/14 7:26:37.577 PM com.apple.quicklook.satellite[1869]: Restoration from MetaData complete (0.003s)
6/6/14 7:26:37.597 PM com.apple.quicklook.satellite[1869]: *** attempt to post distributed notification 'ABDistributedDatabaseChangedNotification' thwarted by sandboxing.


Date/Time:     Fri Jun  6 19:26:37 2014
OS Version:    13D65
Application:   com.apple.quicklook.satellite


Backtrace:
0   CoreFoundation                      0x00007fff8df18312 __CFGenerateReport + 242
1   CoreFoundation                      0x00007fff8dd8b102 _CFXNotificationPost + 882
2   Foundation                          0x00007fff91421804 -[NSDistributedNotificationCenter postNotificationName:object:userInfo:options:] + 73
3   AddressBook                         0x00007fff97bb7a16 -[ABAddressBook nts_RestoreFromMetaDataIfNeededAndTriggerSync:] + 472
4   AddressBook                         0x00007fff97b21ca9 -[ABAddressBook nts_RestoreFromMetaDataIfNeeded] + 22
5   AddressBook                         0x00007fff97b21c39 -[ABAddressBook nts_DoInitialImports] + 157
6   AddressBook                         0x00007fff97b1e13f ABRunWithLock + 166
7   AddressBook                         0x00007fff97b1b994 +[ABAddressBook nts_SharedAddressBook] + 129
8   AddressBook                         0x00007fff97b1b86e +[ABAddressBook nts_CreateSharedAddressBook] + 49
9   AddressBook                         0x00007fff97b1b6e1 +[ABAddressBook sharedAddressBook] + 69
10  AddressBook                         0x00007fff97b1b5f7 +[ABAddressBook addressBookWithDatabaseDirectory:options:] + 56
11  AddressBook                         0x00007fff97b8b36a +[ABAddressBook(ABAddressBookHackery) emptyMemoryBackedAddressBookWithOptions:] + 39
12  AddressBook                         0x00007fff97c230fe +[ABAddressBook(ABAddressBookHackery) provisionalMemoryBackedAddressBook] + 106
13  AddressBook                         0x00007fff97beb106 -[ABVCardParser people] + 41
14  Contact                             0x000000010880269c Contact + 9884
15  QuickLook                           0x00007fff8b2dbe23 _QLThumbnailRequestCallGenerator + 585
16  QuickLookSatellite                  0x0000000107d75249 main + 6233
17  QuickLookSatellite                  0x0000000107d766aa _QLUUIDForRequest + 150
18  QuickLookSatellite                  0x0000000107d74fa4 main + 5556
19  QuickLook                           0x00007fff8b30c181 _Z18QLTryCatchAndCrashU13block_pointerFvvE + 17
20  libdispatch.dylib                   0x00007fff93f0e1bb _dispatch_call_block_and_release + 12
21  libdispatch.dylib                   0x00007fff93f0b28d _dispatch_client_callout + 8
22  libdispatch.dylib                   0x00007fff93f0d673 _dispatch_queue_drain + 451
23  libdispatch.dylib                   0x00007fff93f0e9c1 _dispatch_queue_invoke + 110
24  libdispatch.dylib                   0x00007fff93f0cf87 _dispatch_root_queue_drain + 75
25  libdispatch.dylib                   0x00007fff93f0e177 _dispatch_worker_thread2 + 40
26  libsystem_pthread.dylib             0x00007fff93154ef8 _pthread_wqthread + 314
27  libsystem_pthread.dylib             0x00007fff93157fb9 start_wqthread + 13
6/6/14 7:26:37.609 PM com.apple.quicklook.satellite[1869]: Database file is empty: /Network/Servers/server.domain.com/path/to/user/Library/Application Support/AddressBook/AddressBook-v22.abcddb
6/6/14 7:26:37.618 PM com.apple.quicklook.satellite[1869]: CoreData: error: (3) access permission denied
6/6/14 7:26:37.622 PM com.apple.quicklook.satellite[1869]: Unknown error reading database file, will attempt reimporting: Error Domain=NSCocoaErrorDomain Code=256 "The file couldn’t be opened." UserInfo=0x7f8ff2c4c6e0 {NSSQLiteErrorDomain=3, NSUnderlyingException=error during prepareSQL for SQL string 'pragma auto_vacuum=2' : access permission denied} {
    NSSQLiteErrorDomain = 3;
    NSUnderlyingException = "error during prepareSQL for SQL string 'pragma auto_vacuum=2' : access permission denied";
}
6/6/14 7:26:37.622 PM com.apple.quicklook.satellite[1869]: Move Address Book store at /Network/Servers/server.domain.com/path/to/user/Library/Application Support/AddressBook/AddressBook-v22.abcddb to /Network/Servers/server.domain.com/path/to/user/Library/Application Support/AddressBook/AddressBook-v22.abcddb.B60A7CE5-DE9C-47D2-B599-AA6BFCE37DC7.unknown
6/6/14 7:26:37.662 PM com.apple.quicklook.satellite[1869]: Could not replace store at file:///Network/Servers/server.domain.com/path/to/user/Library/Application%20Support/AddressBook/AddressBook-v22.abcddb.B60A7CE5-DE9C-47D2-B599-AA6BFCE37DC7.unknown from file:///Network/Servers/server.domain.com/path/to/user/Library/Application%20Support/AddressBook/AddressBook-v22.abcddb: Error Domain=NSSQLiteErrorDomain Code=3 "The operation couldn’t be completed. (NSSQLiteErrorDomain error 3.)" UserInfo=0x7f8ff2e450a0 {NSFilePath=/Network/Servers/server.domain.com/path/to/user/Library/Application Support/AddressBook/AddressBook-v22.abcddb.B60A7CE5-DE9C-47D2-B599-AA6BFCE37DC7.unknown, reason=Failed to replace destination database} {
    NSFilePath = "/Network/Servers/server.domain.com/path/to/user/Library/Application Support/AddressBook/AddressBook-v22.abcddb.B60A7CE5-DE9C-47D2-B599-AA6BFCE37DC7.unknown";
    reason = "Failed to replace destination database";
}
6/6/14 7:26:37.669 PM com.apple.quicklook.satellite[1869]: CoreData: error: (3) access permission denied
6/6/14 7:26:37.673 PM com.apple.quicklook.satellite[1869]: 0x7f8ff2e3e750: ManagedObjectContext (ABAddressBook) could not create the store at path: </Network/Servers/server.domain.com/path/to/user/Library/Application Support/AddressBook/AddressBook-v22.abcddb> - creation error: Error Domain=NSCocoaErrorDomain Code=256 "The file couldn’t be opened." UserInfo=0x7f8ff2c5d9c0 {NSSQLiteErrorDomain=3, NSUnderlyingException=error during prepareSQL for SQL string 'pragma auto_vacuum=2' : access permission denied} {
    NSSQLiteErrorDomain = 3;
    NSUnderlyingException = "error during prepareSQL for SQL string 'pragma auto_vacuum=2' : access permission denied";
}
6/6/14 7:26:37.736 PM com.apple.quicklook.satellite[1869]: Error obtaining permanent ID: Error Domain=NSCocoaErrorDomain Code=134020 "The model configuration used to open the store is incompatible with the one that was used to create the store." UserInfo=0x7f8ff2d0fdb0 {NSUnderlyingException=Can't resolve how to assign objects to stores; Coordinator does not have any stores}
6/6/14 7:26:37.736 PM com.apple.quicklook.satellite[1869]: Error obtaining permanent ID: Error Domain=NSCocoaErrorDomain Code=134020 "The model configuration used to open the store is incompatible with the one that was used to create the store." UserInfo=0x7f8ff2e3da50 {NSUnderlyingException=Can't resolve how to assign objects to stores; Coordinator does not have any stores}
6/6/14 7:26:37.738 PM com.apple.quicklook.satellite[1869]: Error obtaining permanent ID: Error Domain=NSCocoaErrorDomain Code=134020 "The model configuration used to open the store is incompatible with the one that was used to create the store." UserInfo=0x7f8ff2e44ef0 {NSUnderlyingException=Can't resolve how to assign objects to stores; Coordinator does not have any stores}
6/6/14 7:26:37.740 PM com.apple.quicklook.satellite[1869]: Error obtaining permanent ID: Error Domain=NSCocoaErrorDomain Code=134020 "The model configuration used to open the store is incompatible with the one that was used to create the store." UserInfo=0x7f8ff2e4b2c0 {NSUnderlyingException=Can't resolve how to assign objects to stores; Coordinator does not have any stores}
6/6/14 7:26:37.740 PM com.apple.quicklook.satellite[1869]: Error obtaining permanent ID: Error Domain=NSCocoaErrorDomain Code=134020 "The model configuration used to open the store is incompatible with the one that was used to create the store." UserInfo=0x7f8ff2e4b490 {NSUnderlyingException=Can't resolve how to assign objects to stores; Coordinator does not have any stores}
6/6/14 7:26:37.741 PM com.apple.quicklook.satellite[1869]: Error obtaining permanent ID: Error Domain=NSCocoaErrorDomain Code=134020 "The model configuration used to open the store is incompatible with the one that was used to create the store." UserInfo=0x7f8ff2e4c6e0 {NSUnderlyingException=Can't resolve how to assign objects to stores; Coordinator does not have any stores}
6/6/14 7:26:37.741 PM com.apple.quicklook.satellite[1869]: Error obtaining permanent ID: Error Domain=NSCocoaErrorDomain Code=134020 "The model configuration used to open the store is incompatible with the one that was used to create the store." UserInfo=0x7f8ff2e4ce10 {NSUnderlyingException=Can't resolve how to assign objects to stores; Coordinator does not have any stores}
6/6/14 7:26:37.743 PM com.apple.quicklook.satellite[1869]: Error obtaining permanent ID: Error Domain=NSCocoaErrorDomain Code=134020 "The model configuration used to open the store is incompatible with the one that was used to create the store." UserInfo=0x7f8ff2e4f9c0 {NSUnderlyingException=Can't resolve how to assign objects to stores; Coordinator does not have any stores}
6/6/14 7:26:37.746 PM com.apple.quicklook.satellite[1869]: Error obtaining permanent ID: Error Domain=NSCocoaErrorDomain Code=134020 "The model configuration used to open the store is incompatible with the one that was used to create the store." UserInfo=0x7f8ff2c37520 {NSUnderlyingException=Can't resolve how to assign objects to stores; Coordinator does not have any stores}
6/6/14 7:26:37.749 PM com.apple.quicklook.satellite[1869]: Error obtaining permanent ID: Error Domain=NSCocoaErrorDomain Code=134020 "The model configuration used to open the store is incompatible with the one that was used to create the store." UserInfo=0x7f8ff2e55820 {NSUnderlyingException=Can't resolve how to assign objects to stores; Coordinator does not have any stores}
6/6/14 7:26:37.750 PM com.apple.quicklook.satellite[1869]: Rethrowing (from setValue:forProperty:error:account:) NSInvalidArgumentException: *** -[__NSPlaceholderArray initWithObjects:count:]: attempt to insert nil object from objects[0]
6/6/14 7:26:37.751 PM com.apple.quicklook.satellite[1869]: ABVCardParser: importToPerson: Exception: *** -[__NSPlaceholderArray initWithObjects:count:]: attempt to insert nil object from objects[0]
6/6/14 7:26:40.957 PM com.apple.quicklook.satellite[1869]: Error obtaining permanent ID: Error Domain=NSCocoaErrorDomain Code=134020 "The model configuration used to open the store is incompatible with the one that was used to create the store." UserInfo=0x7f8ff2d32220 {NSUnderlyingException=Can't resolve how to assign objects to stores; Coordinator does not have any stores}

Pete,

One more thing I need to highlight. Every time the Mavericks client is rebooted and the user with the networked home directory logs in, Spotlight reindexes the computer/account. This is a several hour long process.

I do not see this behavior with users using PHDs or local home directories.

Unfortunately, things are getting worse too.

Tim

Count me in as well. Clean install of 10.3.9/3.1.2. Restored OD archive from 10.8.5/2.2.2. 10.9.3 clients remain connected AFP after logout, 10.8.5 clients are fine. This is a HUGE problem since our school lab does not allow students to log in to multiple machines. This bug locks them out even after they log off. I'm going to try using our OD replica, which is still running 10.8.5 and see if the problem remains with the Mavericks clients.

One other thing - probably not related - I only use FIle Sharing & Open Directory service, but most of the restored users now show that they belong to 2 groups in addition to our preset: com.apple.access_afp & SMB ACL. Some users are also in several other groups: Address Book ACL, com.apple.access_backup, com.apple.access_ftp, Deprecated Profile Manager Access, iCal ACL, iChat ACL, Mail ACL, VPN ACL. Not sure why these are in there.

-DP

Peteee,

Exactly same issue and exacly same workaround (on 10.8.5 server and 10.8.5 client over AFP)

Just another way for "diagnose" the issue :

- if you go to Preferences System->Printer : Spin and Preferences System crash

- if you create folder on desktop and delete it, it's direcly deleted (no trash folder, you need to relaunch finder for normal state.

- if you rename NeworkUsers/Library/Application Support/AddressBook to AddressBook_bak, all return to normal state, Preferences System relaunch normaly

- if you go to Preferences System -> Accounts, it's bug, need to delete .../Application Support/AddresBook

- if you are on Safari with form complete -> SPIN. delete or renam ../Application Support/AddresBook resolve issue.

- when you rename AddressBook, and launch Preferences System, you can see a new AddressBook forlder created. But with no "Contacts". Then you ca try, close Contacts, copy old AddressBook Data to the new AddressBook folder, and you will see it's disapear after copy, then you recopy and in the second time, AddressBook make the copy.

- And last, after X times (day, or week or ...) .. the problem return 🙂 and users come to me : Safari Spin when i complete a form -> diagnostique, launch Preferences Sytem -> Printer ..it's cras, rename AddressBook and user loose all Contacts !

All seemts to be related to AddressBook folder and Contact application with i think same issue :

Network home users : finder must relaunch. Sometimes, Finder connect correctly to the share on login, sometimes it need to be relaunch.

Regards

Follow Up - same issue with 10.9.3 clients on 10.8.5 server. AFP stays connected in server unil manually stopped or another user logs ionto client machine.