Apache Fehler: pcfg_openfile Fehler 13 beheben

Heute hatte eine meiner Domains auf einmal nicht mehr funktioniert, wofür ich zunächst keine Erklärung finden konnte. Bei jedem Aufruf kam nur eine Fehlerseite zurück, mit der Meldung dass der Zugriff nicht erlaubt ist oder kein Indexdokument vorhanden sein.

Werbung


Da aber beides meines Erachtens nicht zutreffen sollte, machte ich mich also auf die Suche und traf in den error-Logs des Apache2-Webservers auf folgenden Fehler:

[Mon May 22 10:52:42 2006] [crit] [client 123.123.123.123] (13)Permission denied: /var/www/XXX/html/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable

Einige Elemente dieser Fehlermeldung sind von mir gelöscht worden

Wie sich erkennen lässt, „mault“ der Apache wegen einer .htaccess, die seines Erachtens nicht lesbar ist. Nun habe ich also eine solche überhaupt nicht in diesem Verzeichnis, was seltsam war. Ich habe dann eine .htaccess angelegt, die einfach mal testweise auf „chmod 777“ gesetzt, der Fehler ist jedoch trotzdem nicht verschwunden.
Nach einer intensiven Befragung von Google bin ich schlussendlich darauf gekommen, dass es ein rechte Problem zu sein scheint. Apache hat nur schlicht und einfach keinen Zugriff auf das GANZE verzeichnis gehabt. Nach einem Vergleich mit dem Verzeichnis einer anderen Domain und der anschließenden neuen Rechtevergabe funktionierte wieder alles so, wie es sollte. Es waren wohl aus Versehen falsche Benutzerrechte gesetzt worden.
Ob der Apache auf ein Verzeichnis zugreifen kann, lässt sich sehr schnell und unkompliziert feststellen:

su - www-data -s /bin/bash -c "cd /var/www/XXX/html; ls -la"

Wenn der Befehl ein „Permission denied“ ausgibt, dann hat der Webserver definitiv keinen Zugriff auf das Verzeichnis. „www-data“ ist hierbei der Nutzer des Webservers, und „/var/www/XXX/html“ das verzeichnis.

Vielleicht hilfts ja jemandem bei der Fehlersuche 🙂

Veröffentlicht von

Uli

IT-Nerd und Admin

47 Gedanken zu „Apache Fehler: pcfg_openfile Fehler 13 beheben“

  1. Großartig! Das Posting hat mir viel Stress erspart! 🙂
    Jetzt muss mir nur noch wer verraten, warum sich so ganz plötzlich die Rechte verändert haben.. Ich hab da schwer den vsftpd im Verdacht, benutzt Du den auch?

  2. Danke ebenfalls bestens für die gesparte Zeit. Die Seite sollte bei google viel weiter vorne sein, wenn man „unable to check htaccess file, ensure it is readable“ eingibt! (22 Eintröge zu dem Thema waren schlicht unbrauchbar)

  3. Super, hast mit gerade ebenfalls auf die schnelle geholfen.
    Falls es mal jemand braucht bei Confixx.
    Das HTML Dir für z.B. web10 muss dem User web10 und der Gruppe des Webserver gehören.
    Bei Debian z.B. also www-data . ( chown web10:www-data /var/www/web10/html )

    Danke nochmal.

  4. Mir hats nur ansatzweise geholfen.
    Bei mir ist bereits das gesamte Verzeichnis auf chmod 777 -R und der mault immer noch rum…
    Aber trozdem super Post!

  5. Bei mir war auch das Problem:
    „unable to check htaccess file, ensure it is readable“
    Bei einem V Server unter Suse 10 mit Plesk
    Da muss der Webuser für das httpdocs psaserv heissen und nicht, wie automatisch angelegt wurde, psacln
    Das ist ungewöhnlich und wahrscheinlich ein Bug, aber vielleicht hilft es ja jemandem.

  6. Danke! es ist verplüffend, dass man mit der htaccess Meldung so in die irre geleitet wird. aber eigendlich ist die Fehlermeldung ja eh eindeutig und man sollte eigentlich sofort die Ordner und Dateirechte überprüfen! Wäre halt schon gut zu wissen was oder wer die rechte geändert hat! !aufs web chmod o+rx! (Debian Sarge ohne confix oder plesk)

  7. su - www-data -s /bin/bash -c "cd /var/www/XXX/html; ls -la"

    kann ich leider nicht ausführen, weil ich das Passwort nicht kenne. Was kann ich da machen?

  8. HARHAR ein Dauerbrenner. Mittlerweile ist diese Seite aber der erste Treffer bei google.
    Vielen Dank 🙂
    P.S. Bei mir war es das neueste Update meiner Webanwendung. Die Rechte waren auf 700 eingestellt.

  9. Pingback: Krümmelchen
  10. Also ich komme leider immernoch nicht weiter.

    chmod -R a+rwx /home/me/workspace/projectx/web
    chown -R www-data /home/me/workspace/projectx/web

    Im vhost:
    DocumentRoot /home/mkt/workspace/projectx/web

    Order Allow,Deny
    Allow from All

    Und nu?

  11. Ah ok, ein Verzeichnis in dem Pfad zum Document Root war doch nicht auf o-rx gestellt, allerdings bin ich auch bis zu letzt davon ausgegangen, dass das beim DocumentRoot selber reicht…

    Naja, Danke! 🙂

  12. Danke, danke, danke.
    Bei mir trat der Fehler direkt nach der installation von Nagios auf.
    Kurzer hinweis für Strato V-Server (openSuse)
    die Ordner /httpdocs und /httpdsdocs der standard Domain und der subdomains auf Gruppe „www“ setzen und gut.

    also ins Hauptverzeichnis der Domain oder Subdomain wechseln und
    chgrp -R www http*
    tippen und absenden 😉

  13. Vielen Dank!
    Hat mich völlig irrtiert warum er wegen der fehlenden .htaccess rumgemeckert hat statt mir zu sagen das er das Verzeichnis nicht betreten kann.

    :<)

  14. … auch von mir ein DANKE! 😉

    Es ist schon erschreckend, dass man nach so vielen Jahren noch immer die selben Fehler hat (der Post ist von 2006)! 😛

    PS: bei mir hat ebenfalls Plesk dazwischengefunkt -> Lösung: chmod +x httpdocs/

  15. TOP! Ohne diesen Hinweis, hätte ich mir bestimmt das ein oder andere Haar ausgerissen! Danke für die Zeitersparniss und das ich nicht mit Glatze rumlaufen muss… der Winter steht vor der Tür.

Schreibe einen Kommentar zu Philipp Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.