• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Plesk 11.5 roundcube webmail Connection to storage server failed.

sebas

Basic Pleskian
Hi,

I´m having the problem that with certain domains when they try to login in to webmail they ares seeing:
Connection to storage server failed.

Under the login windows and they are now allowed access.

Any solution?
 
It is Roundcube error and usually it is related to wrong login credentials. Need more details from roundcube logs.
 
You can find roundcube logs in /var/log/plesk-roundcube
 
You can find roundcube logs in /var/log/plesk-roundcube

Hi Igor,

this issue seems to be still persistent running Plesk 11.5.30 on CentOS 6.
The log gives back this:
[08-Aug-2013 12:11:29] PHP Warning: date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /usr/share/psa-roundcube/program/include/rcube_config.php on line 408
[08-Aug-2013 12:11:29] PHP Warning: strtotime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /usr/share/psa-roundcube/program/include/rcube_session.php on line 135
[08-Aug-2013 12:11:29] PHP Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CEST/2,0/DST' instead in /usr/share/psa-roundcube/program/include/main.inc on line 1933
[08-Aug-2013 12:11:29 +0200]: IMAP Error: Login failed for [email protected] from 62.245.152.57(X-Real-IP: 62.245.152.57,X-Forwarded-For: 62.245.152.57). Could not connect to localhost:143: in /usr/share/psa-roundcube/program/include/rcube_imap.php on line 191 (POST /roundcube/?_task=login&_action=login)
[08-Aug-2013 12:11:29] PHP Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CEST/2,0/DST' instead in /usr/share/psa-roundcube/program/include/rcube_mdb2.php on line 606

The creditals are 100% correct. Horde works fine.

What I think is a bit strange is that its trying to connect to "Could not connect to localhost:143:"
What is that ":" doing at the end?

Looking forward for getting a solution/fix.

Thanks
Kristian
 
You should check that courier-imapd service is running.

Also check:
# netstat -tulnap | grep 143

If you have SELinux enabled, check its logs too. Try setting it to permissive mode.
 
Hi,

as it works with Horde, Courier-IMAP must be running:
# ps awwx | grep imap
26662 ? S 0:00 /usr/sbin/courierlogger -name=imapd -pid=/var/run/imapd.pid -lockfile=/var/lock/subsys/courier-imapd -start -name=courier-imapd /usr/lib64/couriertcpd -address=0 -maxprocs=40 -maxperip=4 -nodnslookup -noidentlookup 143 /usr/sbin/imaplogin /usr/bin/imapd Maildir
26663 ? S 0:00 /usr/lib64/couriertcpd -address=0 -maxprocs=40 -maxperip=4 -nodnslookup -noidentlookup 143 /usr/sbin/imaplogin /usr/bin/imapd Maildir
26680 ? S 0:00 /usr/sbin/courierlogger -name=imapd-ssl -pid=/var/run/imapd-ssl.pid -lockfile=/var/lock/subsys/courier-imaps -start -name=courier-imaps /usr/lib64/couriertcpd -address=0 -maxprocs=40 -maxperip=4 -nodnslookup -noidentlookup 993 /usr/bin/couriertls -server -tcpd /usr/sbin/imaplogin /usr/bin/imapd Maildir
26681 ? S 0:00 /usr/lib64/couriertcpd -address=0 -maxprocs=40 -maxperip=4 -nodnslookup -noidentlookup 993 /usr/bin/couriertls -server -tcpd /usr/sbin/imaplogin /usr/bin/imapd Maildir
28602 pts/0 S+ 0:00 grep imap
CT-55001138-bash-4.1# netstat -tulnap | grep 143
tcp 0 0 :::143 :::* LISTEN 26663/couriertcpd

SELinux is disabled:
# sestatus
SELinux status: disabled

Regards,
Kristian
 
I get the same error only if courier-imapd service is down. Try connecting to it and authenticating manually via telnet.

What I think is a bit strange is that its trying to connect to "Could not connect to localhost:143:"
What is that ":" doing at the end?

Nothing strange - it's just IMAP. Also ':' in the end just precedes detailed error message, which is empty in you case for some reason.
 
Hi again,

I've found the issue.
It's related to disabled functions in php.ini.
I have yet to find out which one exactly.

Regards,
Kristian
 
Last edited:
Hi,

my problem was related to custom settings in our php.ini.
So if you have not changed your php.ini by hand, then you will not have the same issue.

Are you receiving the exact same error in roundcube and what does your roundcube error_log say?
Have you checked that courier-imap is running and that there are no Firewall-Rules blocking access?

Maybe you could paste the output of the following commands:

# tail -n 10 /var/log/plesk-roundcube/errors
# netstat -tulpen | grep 143
# iptables -L

Regards,
Kristian
 
Sometimes this always solves the problem with roundcube (as it seems to be more sensitive with permissions)

Code:
chown -R popuser:popuser /var/qmail/mailnames/*
 
Hi guys,

Still can't delete.
Send/receive working fine.
I think it is related to trying to delete an email in a full mailbox.
Maybe some php configuration for bin/thrash folder size.

Any idea?
 
If the mailbox is full then deleting with roundcube is going to fail! At least I face the same problems always and the solution always is to increase slightly the mailbox size then thereafter am able to delete ...
 
Hi Abdi,

That is really not good.
Customer will need to open a ticket every time his mailbox get full???
Should we open a ticket to Parallels?
 
Hi Kristian,

Please, any better fix for the issue below?

"If the mailbox is full then deleting with roundcube is going to fail! At least I face the same problems always and the solution always is to increase slightly the mailbox size then thereafter am able to delete ..."
 
Back
Top