From Kolab wiki

Contents 1 I cannot login into the Kolab webadmin frontend 1.1 Problem 1.2 Solution 2 After deleting an user the message User deleted, awaiting cleanup does not vanish 2.1 Problem 2.2 Solution 3 User class 'manager' is denied access or User class 'user' is denied access 3.1 Problem 3.2 Solution 4 deliver.php, forward.php, vacation.php for a user is stuck 4.1 Problem 4.2 Solution 5 I am unable to add a domain with umlauts on the "Service" page of the kolab webadmin 5.1 Problem 5.2 Solution 6 My problem persists 7 Back

I cannot login into the Kolab webadmin frontend

Operating system		Distribution		Kolab version
Applies to:	probably applies to all *NIX systems	Applies to:	probably all distributions	Applies to:	Kolab 2.0 and higher
Found on:	Linux	Found on:	not specified	Found on:	Kolab 2.0 and higher

Problem

You are unable to log into the Kolab webadmin frontend.

Solution

• Is the LDAP server up and running?
• Can you bind to the ldap server?
• Can you authenticate via sasl?

After deleting an user the message User deleted, awaiting cleanup does not vanish

Operating system		Distribution		Kolab version
Applies to:	probably applies to all *NIX systems	Applies to:	probably all distributions	Applies to:	Kolab 2.0 and higher
Found on:	Linux	Found on:	OpenPKG/Gentoo	Found on:	Kolab 2.0 and higher

Problem

This will happen if (1) your kolabd process is not running or (2) if there is a problem deleting the user from any of the slave servers.

Solution

(1)

Check that the process is active:

ps aux | grep kolabd
root     17947  0.0  0.3  18288 15712 ?        S    Mar19   0:00 /kolab/bin/perl /kolab/sbin/kolabd
root     17952  0.0  0.3  18288 14872 ?        S    Mar19   0:00 /kolab/bin/perl /kolab/sbin/kolabd

If it is not running restart it with the following command:

/kolab/bin/openpkg rc kolabd restart

If that does not help try to remove the file /kolab/var/kolab/mailbox-uidcache.db and restarting kolabd again.

if the file get's recreated but the message still does not vanish, check if you did set a kolab slave server on the Services page of the web admin frontend. If that is the case you will need to verify that this slave host is responsive. If it is, check on that server why it fails to delete the user from the LDAP database.

(2)

If you have configured any slave servers of your main Kolab machine, the user needs to be deleted on all of the machines. If deletion fails on any of the slave servers, the message will persist. You will need to check why deletion fails on the slave servers to get rid of the User deleted, awaiting cleanup message.

Distribution specific information (This information might apply if you run Kolab natively on non-OpenPKG distributions)
Gentoo
Run the following command to restart the kolabd process /etc/init.d/kolabd restart

User class 'manager' is denied access or User class 'user' is denied access

Operating system		Distribution		Kolab version
Applies to:	probably applies to all *NIX systems	Applies to:	probably all distributions	Applies to:	Kolab 2.0_beta5
Found on:	Linux	Found on:	OpenPKG/SUSE	Found on:	2.0_beta5

Problem

This occurs when upgrading to kolab2 beta 5 from version 4. Attempting to log in to the web interface results in the given error message. /kolab/var/apache/log/apache-error.log contains the line:

[error] PHP Warning:  in_array(): Wrong datatype for second argument in /kolab/var/kolab/php/admin/include/auth.class.php on line 69

Solution

The setting $params['allow_user_classes'] in session_vars.php was added in beta5 and is probably missing. Run

/kolab/sbin/kolabconf 

to make sure all config files have been regenerated.

deliver.php, forward.php, vacation.php for a user is stuck

Operating system		Distribution		Kolab version
Applies to:	probably applies to all *NIX systems	Applies to:	probably all distributions	Applies to:	probably Kolab 2.0 and above
Found on:	Linux	Found on:	OpenPKG/Debian	Found on:	2.0

Problem

When logging into the Web GUI as a user (not as manager) and when selecting HOSTNAME/admin/user/deliver.php, forward.php or vacation.php, there is no reply from the webserver, not even an error message: The page loads forever, finally times out (depending on the browser). Obviously this issue is Sieve-related: the PHP scripts make a connection to port 2000 on the same (kolab) machine. If they can connect, but if they don't get the according Sieve connection, they remain waiting.

Solution

As root do:

/kolab/sbin/slapcat | grep kolabHomeServer

to find out the hostname that the web interface wants to connect to. This should be the same as what

grep fqdnhostname /kolab/etc/kolab/kolab.conf

yields.

Now try

telnet the_hostname_as_listed_above 2000

on your kolab server. It should tell you something like

"IMPLEMENTATION" "Cyrus timsieved v2.2.12"

If not, try

netstat -tulpen | grep 2000

and see if the IPv4 AND IPv6 sockets are populated by cyrmaster. If they are, everything should work fine. If not, then there is one process on a port 2000 socket which should not be there and prevents the port from talking in SIEVE.

If you find Asterisk running on port 2000, stop it, prevent it from starting again. Restart Kolab. If you urgently need Asterisk, see if you can use it on a different port than 2000.

I am unable to add a domain with umlauts on the "Service" page of the kolab webadmin

Operating system		Distribution		Kolab version
Applies to:	probably applies to all *NIX systems	Applies to:	probably all distributions	Applies to:	probably Kolab 2.1 and above
Found on:	Linux	Found on:	Gentoo	Found on:	2.1-cvs

Problem

The Kolab server does not support Domains with Umlauts directly and the kolab-webadmin does not allow you to add domains like meinbüro.de

Solution

Instead of meinbüro.de you will have to use the alternative notation xn--meinbro-cwb.de. The second notation should cause no problems.

My problem persists

None of the above hints did help you to solve your problem?

Please check your options for getting support and reporting errors.

Back

Back to the troubleshooting index