[gelöst] Fehlermeldung im Zusammenhang mit tmp Verz.

[Samael]

Hallo zusammen,

ich stehe etweas bei folgender Fehlermeldung auf dem Schlauch:


Notice: session_start() [function.session-start]: ps_files_cleanup_dir: opendir(/tmp) failed: Permission denied (13) in /wzx/htdocs/toxxx/index.php on line 109

Was mich völlig durcheinanderbringt ist, das dieser Fehler nur sporadisch auftaucht. Irgendwann ershceint dieser Fehler ganz oben auf der Seite (Rest ist normal) und wenn man rfresht ist dieser wieder weg. Seltsam!!! Fast Mysteriös!

[andrea]

Sieht nach einem Serverproblem aus. Am besten die Fehlermeldung an den Provider weiterleiten.

[Samael]

Werd ich mal machen, danke!

[Samael]

Danke nochmals, lag am Provider! Fehlerhafte Einstellung am Apache/MySQl DB!

[Winters]

Samuel, kannst du Genaueres über die fehlerhafte Einstellung sagen? Ich habe dasselbe Problem, und mein Provider ist manchmal schwer davon zu überzeugen, dass auf deren Seite was nicht stimmt.

[Samael]

Ich habe nur zur Info bekommen das es am Apache selbst lag! Die erkannten das Problem auch sofort, weil das wohl ein bekannter "Bug" bzw. Einstellungsfehler ist.
Sorry, aber mehr hat er mir nicht gesagt!

[tOsE]

Ich kämpfe mit dem Problem leider immer noch - das nervt mich und meine User.

Hier die Info meines Hosters:

> Notice: session_start(): ps_files_cleanup_dir: opendir(/tmp) failed:
> Permission denied (13) in /kunden/tose.de/....   on line 109

Dabei handelt es sich um keine Fehlermeldung sondern vielmehr um einen
Hinweis (PHP hat diesen auch korrekt als "Notice" deklariert).

Die Meldung tritt auf, seitdem wir vor einigen Wochen die Rechte des
globalen tmp Verzeichnisses aus Sicherheitsgründen geändert haben. Es
nunmehr nicht mehr möglich den Verzeichnisinhalt anzuzeigen, oder auf
Dateien zuzugreifen, deren Namen man nicht kennt.
Auch ist ein schreiben oder löschen von Dateien nur noch möglich, wenn
diese von ihnen, bzw. ihren Scripten erstellt wurden.

Da PHP versucht alte Sessions zu löschen, indem es sich den Inhalt des
tmp Verzeichnisses anzeigt, um die Session Dateien herauszufinden, die
gerade dort liegen. Da dies aufgrund der Rechtevergabe nicht mehr
möglich ist erscheint der beobachtete Hinweis.
Alte Sessions werden allerdings auch nach einiger Zeit automatisch von
unseren Servern gelöscht, sodass dies keine Beeinträchtigung darstellt.

Diese Meldung erscheint übrigens in der Standardeinstellung von PHP
nicht, man muss das Error Reporting von PHP also manuell umstellen, um
auch Notice angezeigt zu bekommen. Sie könnten das daher in den
betreffenden Scripten deaktivieren, bzw. sich dafür an die Entwickler
wenden.

Alternativ besteht natürlich auch die Möglichkeit die Sessions in
einem "eigenen" tmp Verzeichnis unterhalb ihres Webspaces abzulegen.
PHP hält hierfür die Funktion Session Save Path zur Verfügung:
http://www.php.net/session_save_path

Kann man da was drehen?

Tom

[Samael]

mmmhh.... klingt ja alles logisch, scheint aber bei den wenigsten Serveranbietern eine Rolle zu spielen, oder irre ich jetzt?
Mich würde auch interessieren ob die Entwickler etwas drehen könne, die User selbst diesen Path setzen oder ob die Serveranbieter es übertreiben.

[andrea]

Also gemäss dem oben zitierten Link http://ch2.php.net/session_save_path kann der User diesen Pfad selbst setzen.

string session_save_path ( [string Pfad])

session_save_path() gibt den Pfad des aktuellen Verzeichnisses zurück, das zum Speichern der Session-Daten verwendet wird. Wenn Pfad angegeben wird, wird der Pfad, unter dem Daten gespeichert werden, entsprechend geändert. Zu diesem Zweck muss session_save_path() vor session_start() aufgerufen werden.

Der session_start() Befehl ist in der Datei "index.php" im Forum Install Directory. Also warum nicht einfach frech ausprobieren: 1. ein Directory mit Rechten 777 im Home-Directory eröffnen und 2. einen session_save_path(...) mal unmittelbar for dem session_start() Befehl einbauen und testen was passiert? Wenn's nicht funktioniert kann man ja den Save der Datei zurückholen (den Du ja sicher vor der Änderung machst  ).


Natürlich alles ohne Gewährleistung - alle Modifikationen an den Standard Sources erfolgen auf eigenes Risiko.

[tOsE]

FANTASTISCH: Es funktioniert! Fehler ist damit behoben!

Vielen vielen Dank!


..Jetzt muss ich mir nur ein Script bauen, dass zwischendurch mal mein Verzeichnis für die Sessions löscht.

[Outsider]

gibt es hierzu schon eine fertige Lösung zum downloaden oder abschreiben?

habe es leider selbst noch nicht hinbekommen, und es stört eben ungemein.
Lokal auf dem eigenen Rechner habe ich das Problem aber noch nicht bemerkt.

mfg

[Mario472]

Also, ich habe mich jetzt lange extrem zurück gehalten, aber 'gelöst'? Ich bitte Euch - gelöst ist es erst, wenn ich selbst nicht umständlich in den Dateien und Verzeichnissen rum machen oder mich mit meinem Hoster ärgern muss, sondern wenn das Board die Lösung von vornherein integriert hat.

Aber es ist ja noch die beta, vielleicht ist es ja bei der fertigen Version 1.0 public auch dann schon dabei.

Ich finde o.g. 'Lösung' gerade für PHP-Noobs ziemlich ungeeignet. Als die Meldung bei mir kam, habe ich hier nach der Lösung gesucht, dies hier gefunden und wieder YaBB SE 1.5.5 installiert.

[robo47]

Also, ich habe mich jetzt lange extrem zurück gehalten, aber 'gelöst'? Ich bitte Euch - gelöst ist es erst, wenn ich selbst nicht umständlich in den Dateien und Verzeichnissen rum machen oder mich mit meinem Hoster ärgern muss, sondern wenn das Board die Lösung von vornherein integriert hat.

Aber es ist ja noch die beta, vielleicht ist es ja bei der fertigen Version 1.0 public auch dann schon dabei.

Ich finde o.g. 'Lösung' gerade für PHP-Noobs ziemlich ungeeignet. Als die Meldung bei mir kam, habe ich hier nach der Lösung gesucht, dies hier gefunden und wieder YaBB SE 1.5.5 installiert.

ich verstehe nicht was dein problem ist, wer ein smf laufen lassen will, der muss halt auch einen dafür geeigneten server/webspace besitzen, damit muss man leben, ausserdem denke ich , dass jeder der ein smf administrieren will auch ein bissel plan von dem was dahinter steckt haben sollte, wenn ned werde doch chartermember, dann macht dir das vieleicht ja sogar einer von den smf-leuten.

[Christian Land]

Also, ich habe mich jetzt lange extrem zurück gehalten, aber 'gelöst'? Ich bitte Euch - gelöst ist es erst, wenn ich selbst nicht umständlich in den Dateien und Verzeichnissen rum machen oder mich mit meinem Hoster ärgern muss, sondern wenn das Board die Lösung von vornherein integriert hat.

Es ist nunmal ein Hoster Problem... wenn Dein Hoster zu dämlich ist seine PHP-Umgebung so zu konfigurieren, dass sie sauber läuft, dann ist das wohl kaum das Problem von SMF... Du wirst Gefahr laufen die gleiche Fehlermeldung bei allen Scripts zu bekommen die ein funktionierendes Session-Management auf File-Basis voraussetzen...

[tOsE]

Ich denke nicht, dass der Hoster "zu blöd", sondern einfach ein wenig mehr auf Sicherheit erpicht ist.

[andrea]

Ab Beta 6 können die Sessions in der Datenbank gespeichert werden.

[Christian Land]

Ich denke nicht, dass der Hoster "zu blöd", sondern einfach ein wenig mehr auf Sicherheit erpicht ist.

Dafür bietet PHP den Safe-Mode, die open_basedir-Restrictions, etc. - man kann ausserdem problemlos dafür sorgen das das Session-Verzeichnis nur jeweils für eine Domain gilt... das auf einem Shared-Server also die Sessions von KundeA und KundeB in verschiedenen Verzeichnissen landen, auf die man nicht gegenseitig zugreifen kann... es ist also eher eine Frage der sauberen Konfiguration als eine Frage der Sicherheit.... zumindest Meiner Meinung nach...

[KIKA]

Ich habe nun das gleiche Problem:

8: session_start(): ps_files_cleanup_dir: opendir(/tmp) failed: Permission denied (13)

...forum/Sources/Load.php
1819

Allerdings verstehe ich die Lösungen hier nicht richtig.
Das sind die Infos, über mein Board:

Versionsinformation:
Forum Version: SMF 1.1 RC1 (ausführlicher)
Aktuelle SMF Version: SMF 1.1 RC1
PHP Version: 4.3.10
MySQL Version: 4.0.24_Debian-4.dotdeb.0-log
Server Version: Apache/1.3.31 (Unix) FrontPage/5.0.2.2635 PHP/4.3.10
GD Version: bundled (2.0.28 compatible)

1. Verstehe ich das richtig, das SMF keinen vollen Zugriff auf dieses /tmp Verzeichnis hat?
2. liegt dieses Verzeichnis nicht in dem Verzeichnis, auf welches ich bei meinem Hoster zugriff habe?
Ich habe Webspace bei Hosteurope, und komm per FTP nur an das Stammverzeichnis meiner Webseite rann.

[KIKA]

Ich habe den Fehler jetzt auch mal an meinen Hoster geschickt, und folgende Antwort erhalten.

der Webserver (php) darf zwar in dem Verzeichnis lesen, aber nicht löschen. Das führt zu der Fehlermeldung.

Wir haben ein eigenes Garbage System und verlassen uns nicht auf PHP, da dies nicht immer zuverlässig funktioniert.

Das scheint ja irgendwie zu bedeuten, das ich den Fehler nicht wegbekomme.
Ist das nun nicht weiter schlimm, oder funktioniert das forum nun nicht richtig?
Wäre schön, wenn mal jemand der sich damit auskennt was dazu schreiben könnte.