Users not disconnected from file sharing

Just looking back to some notes I made quite a while back that when a network managed computer is abruptly disconnected from the server (student unplugs it) and then they can't log back in because the server thinks they are still connected.

This happens in part because of not allowing multiple logins for security reasons.

Using the "idle" settings in Workgroup Manager doesn't seem to fix it either

Another thing to try is set the Total Time to Logout in Minute slower than the default which is 1440 Minutes (24 hours). Set it to about 20 minutes. If the user is idle/disconnected for 20 minutes, the server should cut the connection.

sudo serveradmin settings afp:reconnectTTLInMin = 20

Then run sudo serveradmin settings afp

This will show the reconnectTTLinMin in the results to show it has changed to 20 and not 1440 mins.

I had this set on my system previously but I think it gets changed to default 1440 mins after successive updates/upgrades.

Your comments about not being able to log in make sense. About the time I noticed multiple sessions of file sharing I also started having user login issues. At one point I could no longer log in unless I either logged in with a local admin account and turned off networking or unbound the computer from the network server (I use mobile accounts).

I may have found the fix for this. It may be too early to tell, but since making the change in the AFP settings, I haven't had any duplicate user connections.

Since none of the AFP settings were working, I deciced to compare the AFP settings from a known good server without any issues, to one that was experincing the issue for the majority of the users. Upon further investigation, I found that the good server was using the FQDN for the kerberos realm to authenticate users, while the server with the issues was using the LKDC for authenticating users.

My only guess is that somehow file sharing may have been turned on before Open Directory was set up, and the setting stuck in the AFP settings even after the OD was created. I really have no idea, but it's just a guess.

On the server with the issues, I changed the entry in the AFP pref file itself by typing (substituting the "yourserver" with the FQDN of the server:

serveradmin settings afp:kerberosPrincipal=afpserver/server.yourserver.com@SERVER.YOURSERVER.COM

If you don't use DNS services and Open Directory on your server, your machine will use the LKDC, so don't apply these settings.

Has everyone updated Server.app to version 3.1.1?

I have found the disconnection problem has largely gone away since the latest updates to Server and the users pane actually reflects the correct amount of connections logged in when comparing on ARD. Combined with the shorter afp:reconnectTTLInMin = 20 setting even users who pull the plug on/crash clients are able top log in again without having to manually disconnect them on the Server>Filesharing>ConnectedUsers.

I have had the odd time where I have had to manually disconnect a user but the update has proven a vast improvement over the past week with users not hitting our helpdesk with login/out issues.

same here. So far i see no problems at all. the file sharing in server.app shows actually 2 users for 1 active user, but thats okay. there is no problems at all. also mail is working again and the internet accounts are fine too. just waiting for bugfixes sometimes helps 🙂

OK,

So initially I thought I had a fix, but after a day and a half of the server being on, the problem started to come back. For some reason it did seem to be less prevelant for some users, while other users are now showing up 5-15 times instead of the 1-4 as before.

I have also discovered that servers running 10.6, 10.7, and 10.8 are also having this issue with random users, all of whom are using 10.9 Mavericks.

I now believe this issue to be at the root of Mavericks OS, not just Mavericks Server.

I just read your post and I remember the multiple entries of logged in users under 10.6-8 and usually the AFP was showing signs of the CPU maxing out at the same time. I know its probably not applicable in your case but we always keep our servers at the latest level OSX above any older OSX clients(as recommended by Apple in training). In fact as the Mavericks OS is now free we have levelled the network out to 10.9.2 on all 350 macs and servers.

All I can say is that I have had very little instance of the users not disconnecting since Server 3.1.1 over the past few weeks and only one instance where one server showing duplicate log ins had to be restarted as it had crashed during the busy part of the day. Hope you sort stuff out

Can someone tell me if i am thinking of these settings correctly. I believe I have an understanding of the sleep and idle times, but confused how the reconnect TTL comes into play.

afp:idleDisconnectTime ids the amount of time that a user will will be disconnected who has no activity, but is connected to the server.

afp:clientSleepTime is for when a machine has gone to sleep, and the server holds that connection or a defined period of time so that the user can resume thier session.

afp:reconnectTTLInMin is after the users connection has been idle for the idle time or asleep fo the sleep time, this is how much additional time until the connection is dropped.

Mike,

Have you made any changes to the default AFP or SMB settings? Just out of curiosity, are all your clients connecting to the servers under SMB or AFP? Are clients connecting through bonjour or direct with IP?

Hi, I havent made any big changes to AFP and I dont use SMB at any price as it doesnt have the data rate that AFP does(or at least till SMB2 the latest update by Apple etc). All our clients connect via AFP and LDAP/Open directory. All clients have static IP's and are bound to the directory and I run DHCP for these on the servers also.

I quote some old notes on afp byJohn De Toye > "The‘aggressive reconnect.’ This was implemented to allow

for minor network interruptions. When a client drops the connection to the server

accidentally (a network burp), the server will allow the session to remain active for a period

of time. Meanwhile, the client goes into panic mode (not ‘kernel panic’ mode - just a low

state of paranoia) and aggressively reattaches itself to the server, if possible. The problem is

that this disconnect may be an idle timeout/logout - and the client will try to reconnect. Or it

may be a logout and sleep by a portable, and the server interprets it as an accident. The

default timeout for this is 1440 minutes - a tad bit long."

Hence I set my TTL rate as below. Hope this helps.

sudo serveradmin settings afp:reconnectTTLInMin = 20

I too am now having this problem. My home directory server is an Xserve running Mac OS X 10.6.8 Server, but my clients are running Mac OS X 10.9.2. This problem began with our upgrade to Mavericks.

Updated server and clients to 10.9.3 did not fix issues, please call apple enterprise support so they can get their hands sooner, I already did.

All,

I was having the same issues with my OS X server (Mavericks) having thousands of connected users that were not disconnecting (multiples of same accounts). I was able to finally fix this issue by doing the following inside of Server.app: Go to the Users section under Accounts. For each user, select the user then click on the gear icon on the lower left portion of the Users window. Select `Edit Access to Services' and make sure the account has File Sharing access. My user accounts did not, but were still able to access file sharing. Once I made that change, the issues went away. Hope this helps.

This is a Maverics client issue not a Maverics server issue. It has been a huge hassle for us and I sure hope Apple is working on a fix.

I wrote a simple logouthook that seems to fix the issue.

#!/bin/bash

umount -f /Network/Servers/INSERT-YOUR-SERVER-NAME/Volumes/Users

add this to

com.apple.loginwindow

*update*

This seems to cause user keychain prompts so its not a complete fix.

Did OS X Server 3.1.2 help something or is everybody still having this issue?