Q: Users not disconnected from file sharing

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.

Dear,

Some one can make a script for that (all command are su ) :

serveradmin command afp:command = getConnectedUsers

We list all users (in this sample only me):

afp:timeStamp = "2014-06-10 22:54:31 +0200"

afp:usersArray:_array_index:0:flags = 1

afp:usersArray:_array_index:0:serviceType = "afp"

afp:usersArray:_array_index:0:sessionID = 8

afp:usersArray:_array_index:0:name = "admin"

afp:usersArray:_array_index:0:sessionType = "tcp"

afp:usersArray:_array_index:0:state = 1

afp:usersArray:_array_index:0:disconnectID = 0

afp:usersArray:_array_index:0:ipAddress = "192.168.22.234"

afp:usersArray:_array_index:0:lastUseElapsedTime = 55

afp:usersArray:_array_index:0:loginElapsedTime = 56

afp:usersArray:_array_index:0:minsToDisconnect = 0

afp:timerID = 1

 

serveradmin command

afp:command = disconnectUsers

afp:message = You are disconnected

afp:minutes = 0

afp:sessionIDsArray:_array_index:0 = sessionIDXXX

 

then CTRL+D

 

XXX must be sessionID result from first command, in the above sample :

afp:usersArray:_array_index:0:sessionID = 8

Then the command :

afp:sessionIDsArray:_array_index:0 = sessionID8

And just need how find only "idle/disleep" users.

I think a launch (cron) plist who check every 5 minutes for "sleep/..."  and disconnect theses users ?

I know, when a users have a sleep connection on the server and connect to another computer with another IP, Mail Crash, Firefox crash, AddressBook crash, Safari crash. .. the mac become just a screen

Regards

IMO, writing a script to disconnect users is likely masking the problem.

I've started diving into logs in more detail on the server but nothing conclusive so far.

Is anyone experiencing collabpp crashes on the server?

I may have found a fix. Our users belong to a group that has a specific folder on the server for their Home directories. If I look at the service access for the Group, File Sharing is checked. If I look at the service access for a User, File Sharing has a line through it and is greyed out. I tried several things, but when I unchecked File Sharing for the group, I was then able to edit the individual Users access. I unchecked File Sharing for the User, and then re-checked it for the Group. I also toggled allow user to log in. It seems to be working correctly now and the AFP connections end aboyut 15 seconds after log out. I'll keep testing. Fingers crossed! -DP

Interesting.  I just checked and it turns out I have the same thing.  Users are in a group, Users have correct permissions, the group itself doesn't.  I'll change those now and see if I notice a difference.

Make sure to toggle off/on "Allow user to log" in (click OK for each) after setting the service access - that changes the greyed-out line to a greyed-out checkmark. I also removed the "Depricated Profile Manager Access Group" that appeared from the users. All still seems to be working well here.

This is working for me as of right now... Great catch!

>If I look at the service access for a User, File Sharing has a line through it and is greyed out.

For me I didn't have the greyed out problem, Users showed they had access to file shares and everything appeared happy.  I did have a discrepancy between File Sharing Group permissions and File Sharing User permissions who were members of said group.

Now with User permissions matching Group permissions, I've had accounts logging out properly after a disconnect.

I've been spot checking it all day, currently at 3 active users, which is the first accurate count I've seen.

I think we're on the right track but there are still random occurances. Users with identical settings - some stay connected and others don't. I also noticed that new users created in the same group have all services active and belong to all groups, despite the template. Maybe it has to do with restoring from an OD archive?

Updated clients and server to 10.9.4 and did not fix it, I am still having the same issues

Hey guys,

If you are still interested, I've answered this on  another post

Mavericks network homes

It's just creating a logout hook script which force unmounts the network share.

Chiming in...

I'm having similar issues. In my case, even though the user is being disconnected from their shares server side, AppleFileService is still holding onto some of their files. I found this out because most of my users are set to not allow login from multiple machines and some were getting login failure messages even though they were "disconnected" from the server (connection didn't show up in the "Connected Users" pane of Server, nor did they show up using

serveradmin command afp:command = getConnectedUsers

However, when I open up Activity Monitor on the server, select the open AppleFileServer process and view "Open Files and Ports", I can see that it is still "using" several of the files in the home folder of the disconnected user. I suspect that this is also at the root of the problems with writing sqlite3 db files (see posts above). lsof has also been an invaluable tool for sussing these out.

So - now that gives rise to a few questions, eh?

-Why is AppleFileService holding on to these files?

-How can we get it to stop?

-Is there any command for "releasing" those files as a workaround (other then killing the AppleFileServer process altogether - which would screw all the other current users...).

I, too have tweaked many of my AFP settings to get my server to let go of users in a timely way... and maybe there are a few more tweaks yet to come.

Stay tuned, True Believers!

-Paul

I've been having some of the same issues as most of you: users not disconnecting properly and causing permissions problems with files, shares going missing for users when they log back in, trouble copying more than one file and even some error messages when trying to copy a single file.

I believe now that it's related to Apple's brand new SMB2 implementation so I've turned off SMB access for all of my shares and enabled file sharing for our main user group.... that seems to have fixed the biggest problems for today. However I'm still noticing a few extra sessions for a few users... yet to see if that manifests in problems with access or permissions yet...

10.9.4 and server 3.1.2

Almost a year later and Apple still has not fixed many issues with OS X 10.9 (.5) & Server - the latest rendition 3.2.1 has many of the same issues - even the most simplest thing -- disconnecting multiple users cannot be resolved - AppleShareIP could do that (what was that - 17 years ago) ...integration with Workgroup Manager - poor to fair... I used to use the Radius Server in 10.5.8 but decided to update my systems - guess what no more GUI, even though it had no real features it was fairly decent for my needs - now I do that via command line --  I bought 2 servers for the purpose of using the caching software for my iPads, based on my SE's recommendation -- you know what wasn't supported - that's right iOS 8... last year we got crushed in September by iOS7 updates (before I managed to get a firewall filter in place to put a throttle on it) - so we were all set with our caching servers; this September, due to Apple CDNs not routing via Verizon FIOS properly, we suffered through 5 days of updates lasting any where from 11-42 hours!! -- so if the Caching servers had worked then we could've completed some updates in reasonable time ...

I hope the deal with IBM brings on board someone with much better network management skills because - Apple OS X, the promise of 1999, is no longer making it easy - just harder than it should be...  over 25 years of using Apple & Mac products - I am very disappointed & feel disconnected.

Yes - It's incredibly frustrating and disappointing. I've just been ignoring the phantom AFP connections since it doesn't affect the users logging in elsewhere. The only time I have to disconnect users is when the computer crashes while they are logged in. Not being able to disconnect multiple users is a pet peeve of mine as well.