403 op webmail en phpmyadmin (mod_ruid probleem?)

[Blacky]

Helaas weet ik niet sinds wanneer maar onze gebruikers krijgen een 403 op webmail en phpmyadmin op een Directadmin server.
Via http://het.ip.ad.res/webmail is webmail en phpmyadmin goed te gebruiken. Er draait mod_ruid2 op, dus je zou bijna zeggen een virtual_host2 probleem, maar die conf file staat hetzelfde als op een andere DA server waar alles wel gewoon op werkt.

De log zegt dit:

/var/www/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable
Er staat daar geen .htaccess... die staat wel in /var/www/roundcubemail bijvoorbeeld. Maar dat is normaal, is op de andere server ook zo.

De rechten lijken goed te staan:

-rw-r--r--. 1 webapps webapps 44 May 27 2013 index.html
lrwxrwxrwx 1 webapps webapps 46 Jul 31 03:38 phpMyAdmin -> /var/www/html/phpMyAdmin-3.5.8.2-all-languages
drwxr-xr-x 8 webapps webapps 4.0K Jul 31 03:38 phpMyAdmin-3.5.8.2-all-languages
-rwxr-xr-x. 1 webapps webapps 68 May 27 2013 redirect.php
lrwxrwxrwx 1 webapps webapps 19 Oct 23 03:38 roundcube -> roundcubemail-0.9.5
drwxr-xr-x 10 webapps webapps 4.0K Oct 23 03:38 roundcubemail-0.9.5

Ik heb ook hier naar gekeken maar dat hielp ook niet:
http://help.directadmin.com/item.php?id=363

Verder heb ik een ./build rewrite_confs en "./user_permissions all" gedaan, hielp ook niet, ook phpmyadmin en webmail rebuilden gaf geen soelaas.
De hele mod_ruid nog eens opnieuw gedaan volgens deze gids:
http://wiki.amservers.nl/Mod_ruid2
heeft ook niets geholpen.

Ik ben even door ideeën heen. Behalve dat ik evt. vannacht eens een ./build all d kan doen.

Weet hier misschien iemand een fix ervoor?

[dennis0162]

Zeker weten dat er in /var/www/ (en dus niet in /var/www/html) geen .htaccess staat?

In /var/www/html staat Roundcube, Phpmyadmin etc.

[NederHost]

Heb je al gecontroleerd of Apache wel execute-rechten heeft op /var/www en onderliggende directories? Eventueel eenvoudig te fixen met iets als:

chmod a+X /var/www

of, op eigen risico:

chmod -R a+X /var/www

om het gelijk recursief te doen.

[Blacky]

Dennis: Ja, zeker weten, gecontroleerd op de werkende en op de niet werkende server. De .htaccess staat wel binnen de roundcube directory.
NederHost: Als apache daar geen juiste rechten zou hebben, dan zou het ook niet werken op basis van het ip adres, toch?
De rechten staan op beide servers gelijk daar heb ik naar gekeken, dus dat kan het niet zijn.

[systemdeveloper]

Op ipbasis draai je de phpmyadmin onder de apacheuser, op domeinbasis onder de user.Dus je moet eerst even kijken welke user het is en dan 'su' je even naar 1 van die users en kijk je of je met 'cd' in elke directory in het pad /var/www/html kunt komen. (dus in /var, /var/www en /var/www/html)Die htaccess melding staat eigenlijk los van de htaccess maar geeft aan dat óf apache, óf de user waaronder apache draait ergens geen access heeft in dat pad. Omdat je er op ipbasis wel aan komt, heeft de apache dus wel access, maar de gewone users niet.

[Blacky]

Dat was de oplossing Systemdeveloper, het problem. Beetje door de bomen het bos niet meer zien van mijn kant denk ik:
Op de niet werkende server:
dr-xr-x---. 10 webapps apache 4.0K Oct 12 01:53 www
Op de werkende server:
drwxr-xr-x 9 root root 4096 Jan 8 01:39 www

Dus teruggezet naar eigenaar root en dan 755 erop. Ik weet nog niet helemaal waarom die webapps:apache opeens als user op die directory stond, maar dat kan gebeurt zijn bij m'n herstelpogingen.
Alles werkt in elk geval weer. thanks!

[DutchTSE]

Wij zijn ook tegen dit probleem aangelopen en chmod 711 of 755 lost het inderdaad op. Is opgetreden sinds de laatste DA versie waarin mod_ruid2 groepen op none is gezet. Op nieuwe installaties staat /var/www wel goed omdat de installer dit goed zet. John en Mark vonden het niet nodig dit voor bestaande installaties in een update mee te nemen met dit probleem als gevolg.

[Blacky]

Ja dat zag ik ook al staan, maar verwachtte geen problemen omdat het minstens tot eergisteren goed gelopen heeft. Dit was een oude installatie inderdaad. De andere twee zijn nieuw.
Ik heb het idee dat de installatie van het Mediacp van Castcontrol de rechten op 550 geknald heeft of zoiets. Die wil standaard naar /var/www/html installeren en dan moet je tijdens de installatie aangeven dat je ergens anders naar toe wilt. Best kans dat die er toch mee geknoeid heeft.
Vanmiddag eens het setup script bekeken en die wijzigt ook gewoon je php.ini zonder iets te zeggen of te vragen. Niet echt schokkende wijzigingen, maar het is toch wel netter om het even aan te geven tijdens zo'n installatie.