Mavericks Server Keychain not properly storing information network users.

Likewise, same problem, nothing "works" except restarting, this is on 10.10.2 with network home folders.

We have the same problems with 10.2.2, network home folders.

Mail, Calendar, ... works only once or after after restart ! Logout - Login : Mail asks endless for the passwords.

Now I connected as root from another computer with ssh, and there are many user-processes runnig after logout !!!

If kill them by the Terminal, the network user can login and Mail.app works.

(at)AppleSupport: Please fix the user-logout !!!

Best,

Luda

PS.

Running processes after logout:

Load Avg: 0.94, 0.89, 0.84 CPU usage: 0.0% user, 0.49% sys, 99.50% idle SharedLibs: 19M resident, 23M data, 0B linkedit. MemRegions: 10456 total, 531M resident, 48M private, 154M shared. PhysMem: 2219M used (871M wired), 5968M unused.

VM: 312G vsize, 1070M framework vsize, 0(0) swapins, 0(0) swapouts. Networks: packets: 1924662/775M in, 1960823/1098M out. Disks: 48198/1685M read, 28117/587M written.

Hello

I would like to know if their is a difference between the following clients?

1) Clienst wo have been clean installed with 10.9 or 10.10

2) Clienst wo have been upgraded through the years (e.g. 10.4 to 10.6, 10.6 to 10.9)?

If yes is their a difference between cliens wo updated directly from 10.6 to 10.9 or clients, have been updated from 10.6 to 10.7 to 10.8 to 10.9?

I suppose their must be a difference. Clients 1) & 2)

Regards

Gérard

Hello,

We moved from NFS server to OS X server. The idea was to allow spotlight indexing in mail app. First we go back to 10.6.8 server version, all newer being just for playing. Then we lost all the local keychains items as other peoples in that post. Killing secd process was not satisfactory because login again on the same account made mail apps unresponsive. We write a LogoutHook with that script:

#!/bin/bash

killall -9 secinitd

killall -9 secd

exit

The local items are right, and mail is running after logging again.

Thanks to everybody here, and good luck.

Raoul.

The client version is 10.10.2

Who following this thread are Apple Consultant Network (ACN) members? I am suggesting that we all contact ACN admin e-mail address to get them to escalate this bug which has been around since the introduction of Mavericks (10.9) and is still in the beta of Yosemite (10.10.3). They (ACN) won't do so, however, until enough ACNs that they represent contact them.

I have the " error = 122: Path had bad ownership/permissions" error, too.

But I don't find any bad permissions:

This is what I have:

ls -led /usr

drwxr-xr-x@ 11 root wheel 374 14 Mär 12:36 /usr

ls -led /usr/local

drwxr-xr-x 6 root wheel 204 17 Mär 14:29 /usr/local

ls -led /usr/local/scripts

drwxr-xr-x 3 root wheel 102 17 Mär 15:59 /usr/local/scripts

ls -le /usr/local/scripts/kill_secd.sh

-rwxr-xr-x 1 root wheel 174 17 Mär 15:59 /usr/local/scripts/kill_secd.sh

Does anyone see what I am missing?

I am on 10.10.2 Clients with network accounts on 10.10.2 Server

Clean install this weekend

Greetings

Martin

Hello everybody!

It is a shame that Apple only looks at iOS and forgot OS X. We need a another forum to get heard.

Some here with a good friend at a mac magazine who's not afraid about Apples lawyers?

At least this bug renders OS X Server unusable. I think about speaking to my customers (round about 35 dentists - about 200 Macs) to sign an open letter about massive quality problems and bugs with OS X. Maybe this gets its way to Tim Cook.

This is my list of horrible bugs that have to be fixed ASAP:

1. Keychain and network homes

2. SMB file sharing - problems with access rights

3. speed of file sharing

4. speed of ARD

5. ...

BTW. I never setup a Windows Server with network homes - is it possible and does it work reliable?

Hello Christoph

Same situation here in Switzerland! I have the same envouriments as you with about 50 Ophthalmological Chirurgs. All the bugs you list we have also. It is a shame what the produce (200 new features, 300 new bugs) But I think Apple want to kill their Business Clients and only supply Barbie Computer for Dummies and Mobile Devices for idiots. I am shure in a couple of years none serious business will have OS X on their desk. 10.6.8 was the latest working OS X, all newer are useless and filled with bugs

Regards

Gérard

I want to give some feedback about the "bad ownership/permissions" issue.

The problem was not the permissions of the kill_secd.sh script but of of LaunchAgent plist file.

This file must not be writable from groups and others.

It does not even need to be executable.

When I changed permissions to 644 the script was run but it was complaining in system.log about the keys "UserName" and "GroupName".

After removing these it runs with a charm.

I added some logging to have control over whether it was run or not.

In Terminal:

touch /Users/Shared/kill_secd.log

chmod 777 /Users/Shared/kill_secd.log

In the script:

#!/bin/bash

LOG=/Users/Shared/kill_secd.log

DATE=`date`

echo $DATE - $USER: in killall_secd >> $LOG

/usr/bin/killall -9 secd

/usr/bin/killall -9 secinitd

echo "$DATE - $USER: return code: $?" >> $LOG

Greetings

Martin

Hello Martin

Very nice that you have a workaround, but in my opinion Apple should fix this by a Software Update. The Bug is at least availible for 2 years now and from Apple heard nothing!

Maybe it is a bug that is not on all System but when I look in this forum , many users have this issue!

Regards

Gérard

The workaround builds up on what Benjamin Losch has posted on page 5 of this thread.

So he deserves the flowers.

I totally agree that apple has to fix it but if they don´t we have to help ourselves I guess.

Shame on you, Apple!

My feeling is that the bug could be fixed by adjusting the plist files of seed and secinitd but I have not the time and not quite the knowledge for further investigations.

I only noticed that there are messages in System.log about keys in the corresponding plist files which don't do anything and should be removed.

com.apple.xpc.launchd[1] (com.apple.secd): This key does not do anything: OnDemand

com.apple.xpc.launchd[1] (com.apple.secd): The ServiceIPC key is no longer respected. Please remove it.

In my opinion this is a an evidence of incapability for a company like Apple.

They can´t even implement their own changes into their own code correctly.

This might even be a ticking bomb for future bugs.

I am quite disappointed by Apple and I have been using Apple computers since 1984.

Greetings

Martin

Hello!

Just one short question: Does the script solves the problem with Yosemite, too?

Bye,

eweri

I think so.

I could proof that it kills secd and secinitd when restarting but I did not yet test when logging off.

I will do so in the next days and report.

Greetings

Martin

Okay, here are my experiences with the script: it works with 10.10 !

I just did a few test so I can not tell if it works reliable - but it looks promising. :-)

I had a user that could not use Mail nor Calendar and just installing the script does not work. I had to remove the account data, rebooted the computer and configure the account data again. Than I logged in at the same client with a different user, who had trouble before - no more trouble, logged off and back in as first user and no trouble, too.

So this script looks really promising!

Just for some bug hunting: This bug happens mostly with users using different client computers over time. I have a few users that always login at the same client computer and they never got this problem.

Users that do not experience this problem and use different client computers login into computers that were running 10.8 but their "main"-computer is running 10.10 - but they never login to a computer running 10.10 (or 10.9).

So to me this looks like the problem starts when a user logs into different clients running 10.10 (or10.9?).

Maybe this helps solving this bug,

eweri

BTW. Many thanks to Benjamin Losch for the workaround

For me the script didn't work.

I think this is because the UserName and GroupName keys are not supported (any more?)

I found this in system.log:

6714 Mar 23 11:01:53 imac1 com.apple.xpc.launchd[1] (kill_secd): The UserName key is not supported for non-System services.

6715 Mar 23 11:01:53 imac1 com.apple.xpc.launchd[1] (kill_secd): The GroupName key is not supported for non-System services.

Also I found that after logging out and in again with another user the seed process of the first user was still running.

I remind my script a little to see whats going on:

#!/bin/zsh

LOG=/Users/Shared/kill_secd.log

DATE=`date`

echo $DATE - $USER: in killall_secd >>$LOG

echo "before kill:" >>$LOG

ps Au | grep secd >> $LOG

/usr/bin/killall -9 secd

/usr/bin/killall -9 secinitd

echo "$DATE - $USER: return code: $?" >>$LOG

echo "#######################################" >>$LOG

sleep 1

echo "after kill:" >>$LOG

ps Au | grep secd >> $LOG

echo "#######################################" >>$LOG

Also in the log file I could see that "after kill" the seed process was not running.

I think this is because the script runs under the UID of the user who logs in and he is not allowed to kill processes of the user who was logged in before.

Next I tried to configure a LogOut Script with profile manger but I couldn´t get it running so I finally created a LogouHook.

This technonolgy is depreciated but TADA! It works.

A look into the log file proves that the seed process gets killed

#######################################

Mon Mar 23 12:46:47 CET 2015 - : in killall_secd

before kill:

admin 2593 0.0 0.0 2539620 4160 ?? S 12:45PM 0:00.04 /usr/libexec/secd

root 2676 0.0 0.0 2432772 476 ?? R 12:46PM 0:00.00 grep secd

root 2672 0.0 0.0 2451732 1104 ?? S 12:46PM 0:00.00 /bin/zsh /usr/local/scripts/kill_secd.sh admin

Mon Mar 23 12:46:47 CET 2015 - : return code: 0

#######################################

after kill:

root 2682 0.0 0.0 2432772 428 ?? R 12:46PM 0:00.00 grep secd

root 2672 0.0 0.0 2460948 1124 ?? S 12:46PM 0:00.01 /bin/zsh /usr/local/scripts/kill_secd.sh admin

#######################################

Mon Mar 23 12:47:13 CET 2015 - : in killall_secd

before kill:

root 2815 0.0 0.0 2424580 400 ?? R 12:47PM 0:00.00 grep secd

root 2811 0.0 0.0 2451732 1100 ?? S 12:47PM 0:00.00 /bin/zsh /usr/local/scripts/kill_secd.sh martin

martin 2779 0.0 0.0 2540692 2940 ?? S 12:47PM 0:00.03 /usr/libexec/secd

Mon Mar 23 12:47:13 CET 2015 - : return code: 0

#######################################

after kill:

root 2820 0.0 0.0 2432772 476 ?? R 12:47PM 0:00.00 grep secd

root 2811 0.0 0.0 2461972 1132 ?? S 12:47PM 0:00.01 /bin/zsh /usr/local/scripts/kill_secd.sh martin

#######################################

Creating the LogoutHook is easy:

sudo defaults write com.apple.loginwindow LogoutHook /usr/local/scripts/kill_secd.sh

This has to be done on alle clients.

I feel it would be a little more elegant to use profile manager for this, but it did´t work for me.

I set EnableMCXLoginScripts = TRUE; and MCXScriptTrust = FullTrust; in com.apple.loginwindow but the script was not run.

I would appreciate if any one could explain what I am missing.

Greetings

Martin