Roundcube not loading unless index.php is specified explicitly

harro

Verified User
Joined
Oct 15, 2005
Messages
178
Hello all,

Since the last updates of the various applications, including Roundcube, I have a problem that only occurs on one of my servers:

PROBLEM:

When I navigate to the /webmail alias or straight to /roundcube on any user domain on the server it does not load up, only gives the error:

You don't have permission to access /roundcube/ on this server.


In the http log file of the user domain it reads:

[core:crit] [pid 27480] (13)Permission denied: [client 152.206.200.180:4820] AH00529: /home/client1/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that '/home/client1/' is executable

I redirect all traffic from http to https (setting in DirectAdmin).


What I have tried:

  • reinstalled roundcube, dovecot, exim, apache using custombuild
  • rewrite_confs in custombuild
  • set_permissions.sh in /scripts
  • reinstalled the LetsEncrypt SSL certificate of the user
  • checked that the httpd.conf still reads .php files first


What still functions as expected:


Does anyone have suggestions what the issue (and/or solution) could be?


p.s. I have not used a real domain since there is no more information through the webbrowser than the error message mentioned at the top. I can provide a domain if there is a need.
 
Hello,

How do you run PHP? What are your options?

Code:
cd /usr/local/directamin/custombuild
./build options

What permissions you have? Owner/Group ?

Code:
ls -la /home/client1/
 
Thank you for your response zEItEr,

The roundcube worked fine for years until this latest update (just as a context). The information you requested:

Custombuild Options

Code:
Apache: 2.4.37
mod_ruid2: 0.9.8
ModSecurity: 2.9.2
ModSecurity Rule Set: comodo
Dovecot: 2.3.4
Dovecot configuration: yes
AWstats: no
Exim: 4.91
exim.conf update: yes, release 4.5
BlockCracking: yes
Easy Spam Fighter: yes
SpamAssassin: 3.4.2
SpamAssassin rule updates: daily
ClamAV: 0.100.2
MySQL: no
MySQL backup: yes
MySQL backup directory: /usr/local/directadmin/custombuild/mysql_backups
MySQL compress backups: no
PHP (default): 5.6 as mod_php
PHP (additional): 7.2 as php-fpm
phpMyAdmin: 4.8.3-all-languages
ProFTPD: no
Pure-FTPd: 1.0.47
RoundCube webmail: 1.3.8
Replace "php.ini" with './build all' and './build php_ini': no
Cron for notifications and (or) updates: yes
Cron frequency: weekly
Auto notifications: yes
Run "clean" every time: yes
Run "clean_old_webapps" every time: yes
Run "clean_old_tarballs" every time: yes
Show texts in bold: yes
SquirrelMail: 1.4.23-20180516_0203
Zend Guard Loader: no
ionCube loader: no
Suhosin: no


Owner/Group

Code:
drwx--x--- 12 client1 access    4096 Nov 13 16:32 .
drwx--x--x 24 root      root      4096 Jul  8 05:34 ..
drwx--x--x  4 client1 client1 4096 Apr 22  2018 .appdata
drwx------  2 client1 client1 4096 Nov 26 03:01 application_backups
drwx------  2 client1 client1 4096 Apr 22  2018 backups
-rw-r--r--  1 client1 client1   24 Oct 18  2012 .bash_logout
-rw-r--r--  1 client1 client1  176 Oct 18  2012 .bash_profile
-rw-r--r--  1 client1 client1  124 Oct 18  2012 .bashrc
drwx--x--x  3 client1 client1 4096 Oct 18  2012 domains
drwxrwx---  3 client1 mail      4096 Jan  6  2017 imap
drwxrwx---  9 client1 mail      4096 Jan 15  2014 Maildir
drwxrwx---  2 client1 apache    4096 Nov 27 00:10 .php
drwx------  3 root      root      4096 Apr 22  2018 .pki
lrwxrwxrwx  1 client1 client1   29 Apr 22  2018 public_html -> ./domains/client1.com/public_html
drwxr-xr-x  2 client1 client1 4096 Aug  2  2015 .razor
-rw-r-----  1 client1 mail        34 Sep 14 09:59 .shadow
drwxrwx--x  2 client1 mail      4096 Nov 26 17:02 .spamassassin

Kind regards,

Harro
 
And the client1's domain is running under PHP 5.6 or 7.2? Will the situation change if you switch the PHP version for the domain?

I'd rather disable mod_ruid2 and switch PHP (default): 5.6 as mod_php to PHP-FPM.
 
Thank you for your suggestions. I switched the PHP version to 7.2 for one of the users on that server and it made no difference, still:

Forbidden

You don't have permission to access /roundcube on this server.

Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request


On a test server I tried to change the PHP5.6 from mod_php + mod_ruid2 to PHP-FPM as you suggested but it turns out that there are now 3 or 4 lines of invalid commands for each (sub)domain in each user's httpd.conf, for example:

Code:
php_admin_flag engine ON
php_admin_value sendmail_path '/usr/sbin/sendmail -t -i -f [email protected]'
php_admin_value mail.log /home/admin/.php/php-mail.log


This is a different issue but I can't make this change on a live server if I have to go through hundreds of domains to remove these lines of code. I don't know where they come from because the code is still there when I do ./build rewrite_confs


Anyhow, since switching to PHP7 does not help, I presume that changing PHP5.6 from mod_php to PHP-FPM will not fix this particular roundcube problem.


There must be some clue to the root problem in the fact that




It seems that only for Roundcube there is a problem with the redirect/alias where the server does not recognise that there is an index.php in the folder (cannot get a file listing, I suppose) but the folder does have the rights to read the file if it is explicitly referenced.
 
My full reply is apparently waiting for moderator approval since yesterday, so this should hopefully be released soon
 
I'd rather disable mod_ruid2 and switch PHP (default): 5.6 as mod_php to PHP-FPM.
It both has it pro's and cons. I doubt that changing this would fix this issue. I always run mod_ruid2, even on Centos 7 and never had any of these issues.

I see a "no permission" notice for roundcube in the first post.

Maybe you cantry this:
Code:
cd /var/www/html
chown webapps:webapps roundcube -R
Or is this tried already?
 
Last edited:
On a test server I tried to change the PHP5.6 from mod_php + mod_ruid2 to PHP-FPM as you suggested but it turns out that there are now 3 or 4 lines of invalid commands for each (sub)domain in each user's httpd.conf, for example:


Enable htscanner to resolve it.
 
It both has it pro's and cons. I doubt that changing this would fix this issue. I always run mod_ruid2, even on Centos 7 and never had any of these issues.

I see a "no permission" notice for roundcube in the first post.

Maybe you cantry this:
Code:
cd /var/www/html
chown webapps:webapps roundcube -R
Or is this tried already?



Good day Richard, thank you for your response.

The ownership of the roundcube (sub-)directories are all already set to webapps:webapps (I also ran /scripts/set_permissions.sh). So unfortunately that does not solve the error that occurs.

The error started occurring after a recent update (via custombuild). I have multiple servers and only on this one does this issue now occur.


Kind regards,

Harro
 
Hello Harro.

If zEitEr's tip with the htscanner does not bring a solution, then I don't know if you already tried, but maybe you can uninstall the roundcube installation. Removing the old files and symlinks.
After that build it from scratch again via Custombuild and see if that helps.
I've read you already reinstalled Roundcube, but it does not say if you just install over it or really deleted the files before. If you did, just ignore this idea.

I've also read about some issues occuring after updates when certain mirrors of DA are used. Which might also explain why your other servers do not have that issue.

So if you did not try this before you could try:
Code:
./build set fastest
./build update
./build all d

It's just an idea, but it might be of help.
 
Good day Richard,


Thank you for your idea, I had not completely removed roundcube before so I did that now and then reinstalled it. The result is the same, unfortunately.

So under any user domain using the alias /roundcube gives the FORBIDDEN You don't have permission to access /roundcube on this server error, while using the server hostname with /roundcube works as it should.

Adding the index.php a to the url also leads to the correct loging screen.


It seems that Apache cannot do a directory listing to look for the index.php or index.html in the folder. However it CAN access the file if you specify it.

I don't know what kind of settings would have this effect? I have not changed the directory settings before/after the update I ran recently that lead to the problem. I listed the current directory attributes above (following ./set_permissions.sh several times), and it looks like standard to me...


zEItEr:
I should not have raised the issue following the change from mod_php to php-fpm in this thread (it is not relevant to this discussion). I decided not to change that right now since I do not fully understand the benefits and I prefer not to install additional 'patches' that complicate my set-up just to correct some configuration problem). But thank you for the recommendation and I will have to look into that soon!
 
OK, I see. You are free to keep it. I don't have any other ideas, so probably you need to open a ticket with DA support and get them to check your server from inside.
 
You got the roundcube htaccess file in that folder?

If not look forum here. http://forum.directadmin.com/showthread.php?t=56708
If yes you can maybe change some in that so index.php works even if ..

Optional security headers crosdomain or other security settings for html files, you see for php files these base httpd settings don't work. ;)

CSP headers....

And here infos:
https://help.directadmin.com/item.php?id=365

mod_php debian roundcube https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880194
 
Last edited:
Thank you for those suggestions ikkeben.

I checked and there is a .htaccess.


The links you sent did make me think what was fundamentally different on this server where it does not work and it is the fact that PHP7 is installed (alongside PHP5)!

I checked two other servers that also have php7 (primary php5, secondary php7) and all three give the same error with roundcube on user domains. One server is a test server and on the other apparently no one uses roundcube (never received reports).

Since the PHP5 is set as the primary PHP, I presume that roundcube does not actually use PHP7, right?

Why then does the presence of PHP7 seem to be the cause of the roundcube error on user domains?


In the roundcube/.htaccess file I modified the reference to mod_php5.c (changed it to mod_php7.c) and restarted httpd but no change. That did not seem to be the problem.

With this new information, are there any new ideas what may be the issue?


Perhaps I should seek DA support to check it out, since all three servers were standard DA servers and updated with Custombuild 2.0.
 
Hi Alex,

I am not trying to change the PHP version (I assume that it is php5 since this is the default version), but I was trying to see whether this change improved the problem, following remarks on one of the pages ikkeben referenced.

It did not make a difference. But I now think that there is some issue/interference with PHP7 being installed (as secondary PHP version).

Kind regards,

Harro
 
Add i.php under /var/www/html/roundcube/ with

PHP:
<?php
phpinfo();

open it in a browser and see which PHP version's used there.
 
All the above did not lead to any improvements (although thank you for the suggestions!), so I have opened a ticket with DirectAdmin, hoping that they can identify what the cause of the issue is. It affects only my servers that have two versions of PHP. The other servers, running either PHP5.6 or PHP7, do not have this issue.
 
Back
Top