nach Upload keine Berechtigung Bilder anzuzeigen
Eingetragen von fa_me (14)am 23.07.2008 - 16:34 Uhr in
Hallo zusammen,
zunächst mal die Situation: Habe verschiedene Module zur Bildverarbeitung (Upload, CCK, Views, filefield, filefield_image, usw.) getestet und bin auf das Problem gestoßen, dass ich nach dem Upload keine Berechtigungen habe mir das Bild anzuschauen. So viel zum grundsätzlichen Problem.
Um dem Prob auf den Grund zu gehen habe ich soeben ein völlig frisches (nur Kern-Module) Drupal 6.3 (dutsche Version von drupalcenter.de) aufgesetzt. Danach habe ich folgende Schritte ausgeführt bzw. Einstellungen überprüft:
- upload-Modul (das Kern-Modul) aktiviert
- Berechtigungen für upload-Modul gesetzt (meiner Meinung eig. nicht nötig, da erstaml nur Tests mit admin)
- Das Dateisystem hat den Pfad sites/default/files und das tmp-Verzeichnis sites/default/tmp. Beide Ordner existieren und haben die Berechtigung 777.
- Die Download-Methode steht auf Öffentlich.
Jetzt schreibe ich als admin ein Artikel und hänge diesem ein Bild an. Das Bild wird scheinbar ordungsgemäß hochgeladen und der Artikel wirde ohne Probleme oder Fehlermeldungen gespeichert.
Das Bild wird nun wie gewünscht als Link unter meinem Artikel angezeigt. Wenn ich versuche das Bild über den Link zu öffnen kommt die Fehlermeldung:
"Forbidden
You don't have permission to access /sites/default/files/test.jpg on this server."
Dies wird sehr wahrscheinlich daran liegen, dass die hochgeladene Datei (test.jpg) nun im richtigen Verzeichnis auf dem Server liegt, aber nur Lese- und Schreibberechtigungen für den Eigentümer der Datei hat (600). Wenn ich nun den "Sonstigen" Leseberechtigung gebe (604) funktioniert alles.
So und jetzt endlich zu meiner Frage: Warum wird die hochgeladene Datei mit so wenig Rechten ausgestattet? Liegt das möglicherweise an der Server-konfiguration (Bin bei einem Hoster, bei dem ich wenig Konfig-Möglichkeiten habe, wenn ich ihn nicht kontaktiere)? Oder, hat sich vielleicht etwas an System(Server)voraussetzungen geändert von Drupal 5.8 zu 6.3, denn unter 5.8 habe ich diese Probleme auf gleichem System(Server) nicht.
So, puhh ... Danke schon mal an alle, die sich die Mühe machen das hier überhaupt zu lesen! Ich wäre super froh, wenn mir jemand helfen könnte, da ich schon einige Tage auf der suche bin! Also vielen Dank schon mal!!!
- Anmelden oder Registrieren um Kommentare zu schreiben
Das muss dann aber
am 23.07.2008 - 18:37 Uhr
Das muss dann aber tatsächlich an der Serverkonfiguration liegen, da bei mir die Files zum Beispiel mit 644(rw - r - r) angelegt werden und es somit keine Probleme gibt. Ich selber setze FastCGI (+ suhosin) mit individuellen Berechtigungen pro Webseitenverzeichnis ein, trotzdem gibt es keine Probleme. Ich vermute daher stark, dass deine Serverkonfiguration diese besondere Rechtevergabe bewirkt, was sich sicherlich auch einstellen lässt.
-------------------------------------
Meine Entwicklungen:
www.minis-kuemmersbruck.de | www.hausmeisterteam-glaser.de
Welche Server-Einstellung?
am 24.07.2008 - 10:52 Uhr
Vielen Dank für Deine Antwort! Hast Du vieleicht eine Idee welche Server-Einstellung das sein könnte? Dann könnte ich mich mit der Bitte an meinen Hoster wenden, genau diese Einstellung zu ändern.
Danke schon mal!
php als binary
am 24.07.2008 - 12:06 Uhr
Die Wahrheit ist leider, dass sich schon ziemlich viele Leute (inkl. Webhoster) an dieser Frage die Haare ausgerissen haben. Wenn PHP nicht als Apache-Modul, sondern als Binary mit der Kennung des Users läuft, scheinen PHP-erzeugte Dateien (wie eben beim Upload) zunächst mit den Rechten 600 versehen zu werden (nicht in jedem Fall, wie grandcat richtig anmerkt). Wenn suphp im Einsatz ist, können diese Rechte über die / etc / suphp.conf eingestellt werden (umask).
Aber selbst die Domainfactory hat mit diesem Thema zu kämpfen und patcht z.B. bis auf den heutigen Tag ihre Wordpress-Klick-Install-Versionen mit der PHP-Funktion chmod(), um die leidigen 600 loszuwerden. Ich habe auch schon Hoster einfach mit den Achseln zucken sehen bei diesem Thema. Aber es ist definitiv ein Hoster-Thema, das nichts mit Drupal zu tun hat. Zwar kann man sich mit dem Patchen des Codes auf Applikationsebene helfen, aber das ist weder "Best pratice" im Sinne Drupals noch kann es Aufgabe Drupals bzw. anderer Web-Anwedungen sein, sich in die Sicherheitsstrategien des Servers einzumischen.
Die schnelle, eigenhändige Lösung bietet dieser Thread auf drupal.org, aber eigentlich wäre der Hoster gefragt und das würde ich auch tun (und die Lösung bei Nennung des Hosters hier posten).
Vielen Dank für die Hilfe!
am 24.07.2008 - 19:35 Uhr
Vielen Dank für die Hilfe! Dank der Änderungen (wie über den Link beschrieben) läuft jetzt alles, endlich! =) Habe dennnoch bei meinem Hoster (www.top-hoster.de) angefragt. Sie haben mir mitgeteilt, dass dies ein skribtseitiges Problem (also von mir) sei und es nicht an der Server-Konfiguration liegt. Dank tumblingmug wissen wir es ja jetzt besser. Auch dafür noch mal vielen Dank an tumblingmug!!!
Spaß
am 25.07.2008 - 01:32 Uhr
Sie haben mir mitgeteilt, dass dies ein skribtseitiges Problem (also von mir) sei und es nicht an der Server-Konfiguration liegt.
Kunde ist König: wenn die Zugriffsrechte, welche Bruder PHP für Dateien schreibt, nicht dafür ausreichen, dass Bruder Apache sie lesen und ausliefern darf - so ist dies natürlich keinesfalls durch die Serverkonfiguration bedingt, sondern ein Problem dummer Benutzer, die davongewinkt gehören ...
Na gut. Aber wirklich lachen hab' ich müssen bei des Hosters "Geld-zurück-Garantie", die statistisch als "nicht in Anspruch genommen" mit 100% ausgewiesen wird, und wo der Workflow der "Entscheidungsfindung" bei der "Garantie-Gewährung" wirklich genial beschrieben ist - lesen, lesen!! ^^ ^^ ^^ - Das grenzt stilistisch an Friederike Kempner.