Bekijk Volledige Versie : Open_basedir-melding blijft ook na optie uitzetten
Een php-script genereert een excel-bestand dat wordt gevuld met gegevens uit de database. In het bestand staat in plaats van data de melding:
Warning: tempnam() [function.tempnam]: open_basedir restriction in effect. File() is not within the allowed path(s)...
In DirectAdmin heb ik bij Php Safe Mode Settings de Open Base voor de gebruiker op OFF gezet. Maar de foutmelding blijft.
Moet de instelling direct werken? Heb ik nog een instelling over het hoofd gezien?
websiteondemand
10/08/11, 15:09
Neem aan dat het ook in DA meteen zou moeten werken. Kan het niet zijn dat er ook nog open_basedir restrictions staan in een .htaccess file of in een custom virtualhost configuratie?
In elk geval niet in de htaccess
En een custom config-bestand is er ook niet voor zover ik weet.
websiteondemand
10/08/11, 15:28
Wel vaag trouwens dat hij File() noemt in plaats van bijvoorbeeld File(/var/www/.../generated-excel-sheet.xls). Weet je zeker dat het script niet is verhuisd, er geen componenten zijn geupdate, je niet verhuisd bent van server, enz, waardoor het script een file probeert te laden die er niet is en dan bedenkt dat basedir van toepassing is op een niet-bestaande lokatie?
Staat er in de php.ini nog iets over basedir?
dreamhost_nl
10/08/11, 15:29
Is na de wijziging Apache gereset?
websiteondemand
10/08/11, 15:57
@dreamhost_nl ken DA niet, maar zou DA dat zelf niet snappen als je een native optie t.b.v. open_basedir of safemode aanpast?
Is na de wijziging Apache gereset?
Dat dus, kijk ook even in de error logs of daar geen verdere informatie in staat en zet desnoods in je script de error reporting van php aan (in het geval dat standaard niet zo is).
Wat roep je van bestand aan?
Het probleem is ontstaan nadat de klant naar een andere server is overgezet. In de code wordt het pad niet hardcoded genoemd, dus dat kan het probleem niet zijn lijkt me.
Ik heb de service Httpd gereload, maar daarmee is het probleem niet opgelost. Moet ik hem restarten?
[EDIT]
In de errorlog van apache staat geen melding over het php-bestand of het excel-bestand
Yolk,
Beantwoord deze vraag eerst nog eens...
Staat er in de php.ini nog iets over basedir?
Dit staat er in php.ini
;open_basedir =
Het zal vermoedelijk niet maar men wete maar nooit, kijk eens in het Admin level via Custom httpd configuratie en dan de domeinnaam klikken, of daar misschien nog iets van open_basedir staat?
@dreamhost_nl ken DA niet, maar zou DA dat zelf niet snappen als je een native optie t.b.v. open_basedir of safemode aanpast?
Dat ZOU ie moeten "snappen", maar het gebeurt nog wel eens dat het door, bijvoorbeeld drukte op de webserver of config foutjes, niet goed gaat. Dus bij dit soort rariteiten is het altijd handig om het eens te controleren ;)
Ik vermoed ook dat de user een custom php.ini heeft waar dit in vermeld staat als het verder nergens ingesteld is.
Het zal vermoedelijk niet maar men wete maar nooit, kijk eens in het Admin level via Custom httpd configuratie en dan de domeinnaam klikken, of daar misschien nog iets van open_basedir staat?
Hehe, altijd alle opties nagaan Blacky. Volgens mij heb je nu een goeie tip gegeven. Ik kwam deze regel twee keer tegen:
php_admin_value open_basedir /home/gebruikersnaam/:/tmp:/var/tmp:/usr/local/lib/php/:/usr/bin:/usr/local/bin
Moet ik deze verwijderen? Of iets in aanpassen?
Comment hem eens uit en test wat er gebeurt :)
Uitcommenten zoals ichosting zegt of gewoon weghalen, je kunt ze voor de zekerheid ook effe lokaal in kladblok ofzo opslaan mocht je ze terug willen zetten.
Maar die plek lijkt mij niet de juiste plek om zoiets neer te zetten tenzij je iets specifieks voor dat domein nodig hebt. Zoniet... weghalen.;)
En apache (httpd) herstarten.
Probleem is opgelost dankzij t.bloo (ook wht-er). Een functie in het script werd aangeroepen met een leeg "dir"-argument, met de error als gevolg.
Dat neemt niet weg dat de error het gevolg was van het feit dat open_basedir dus toch actief was, anders had je een andere error gekregen.:)
In elk geval fijn dat het verholpen is nu!
Klopt, die is/was ook actief.
Scripting moest wat beter, dan krijg je dit soort problemen niet hehe :)