Read-only rosters?

Rosters are kept “on the server” right?

Openfire 3.4.5-1.i386.rpm installed on RHEL4, connected to ActiveDirectory ldap server. Groups from the ldap server. I have one user who does not show up in the group on any client for anyone. I don’t get it.

For this invisible user, I can look at the Openfire Admin Console, Users/Groups -> Users -> User Options -> Roster and every item in the user’s roster shows a subscription of ‘to’. For every other user I’ve found, the subscription is ‘both’.

If I try to change the roster via the ‘edit’ button on that web page, and set the subscription to Both, I get this:


org.jivesoftware.openfire.SharedGroupException: Cannot remove item from shared group

at org.jivesoftware.openfire.roster.RosterItem.setGroups(

at org.jivesoftware.openfire.admin.user_002droster_002dedit_jsp._jspService(user_0

at org.apache.jasper.runtime.HttpJspBase.service(

at javax.servlet.http.HttpServlet.service(

at org.mortbay.jetty.servlet.ServletHolder.handle(

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1093)

at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage( 8)

at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084)

at org.jivesoftware.util.LocaleFilter.doFilter(

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084)

at org.jivesoftware.util.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingF

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084)

at org.jivesoftware.admin.PluginFilter.doFilter(

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084)

at org.jivesoftware.admin.AuthCheckFilter.doFilter(

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084)

at org.mortbay.jetty.servlet.ServletHandler.handle(


at org.mortbay.jetty.servlet.SessionHandler.handle(

at org.mortbay.jetty.handler.ContextHandler.handle(

at org.mortbay.jetty.webapp.WebAppContext.handle(

at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollect

at org.mortbay.jetty.handler.HandlerCollection.handle(

at org.mortbay.jetty.handler.HandlerWrapper.handle(

at org.mortbay.jetty.Server.handle(

at org.mortbay.jetty.HttpConnection.handleRequest(

at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.j ava:828)

at org.mortbay.jetty.HttpParser.parseNext(

at org.mortbay.jetty.HttpParser.parseAvailable(

at org.mortbay.jetty.HttpConnection.handle(


at org.mortbay.thread.BoundedThreadPool$

I’d started out with a clean database. I don’t know why this user doesn’t have the same setup as everyone else. I can’t find any noticable differences between him and other users on the Active Directory side. I’m at a loss, both as to how this happened and how to fix it.

Why isn’t the Roster, coming from a read-only Active Directory server, also read-only and fixed? Is there some way I could make it so, at least for the groups coming from the AD server? We’d like every user to show up in the groups we specify, without letting them delete themselves or others from those groups’ rosters.


I have same exception in the same case.

Any solution ?

Shared groups should not be able to be altered between launches of the client. It may aapear that the changes have been commited but quitting the chat app and relaunching should revert shared groups to their original state. You can not ultimately control custom groups the users create in their rosters. But these groups should have no bearing on the shared groups.

As for your one user it generally is a sign of a corrupt account in AD. this does happen from time to time. It could also be the user is ouside your parameters of your baseDN or is the 1001st user in AD. AD by default can only return 1000 results per AD query. For more results you need to change the maxpagefile setting for AD.

Hi Todd,

We have the same problem stated here, but we have only 412 users. So we don’t reach (yet) the 1000 max. User can also be found on the baseDN, as we are searching on the whole LDAP tree. My concern is that it happens for more than one user. Five users already complained about it. I don’t know if there are more users affected.

Perhaps the user accounts are corrupted, as you said, but I don’t understand exactly what you mean. Users appear on the groups, but with subscription=“to” only. We recently upgraded to Openfire version 3.5.2, and users have Spark version 2.5.8. However, we already had this problem before.

Any ideas?

Thank you very much.