nicht angemeldet
Dateien löschen mittels unlink
Hallo Forum!
Ich habe ein sehr sonderbares Problem mit der unlink funktion. Ich möchte per Webinterface die Möglichkeit bereitstellen, Dateien auf den Server hochzuladen und dort auch wieder zu löschen.
Dazu wird die unlink-funktion verwendet.
Ist nun in dem Verzeichnis in dem meine Anwendung läuft das Script für den Upload und das Löschen so klappt das auch.
/usr/www/users/drew/scripts/
Das Verzeichnis in dem die hochgeladenen Dateien abgelegt werden und aus dem sie auch wieder gelöscht werden können ist ein Unterverzeichnis davon:
/usr/www/users/drew/scripts/uploads/
Nun mache ich das löschen so: unlink("uploads/".$filename);
Das klappt auch, ebenso der Upload mittels Webform.
Doch nun das Problem: Ich habe nun alle Administrationsscripte in ein eigenes Adminverzeichnis gelegt:
/usr/www/users/drew/scripts/admin/
Nun müßte das Löschen eigentlich so gehen:
unlink("../uploads/".$filename);
doch das klappt ebensowenig wie:
unlink("/usr/www/users/drew/scripts/uploads/".$filename);
Beide Male kommt die Meldung:
Warning: unlink(/usr/www/users/drew/scripts/uploads/) [function.unlink]: Operation not permitted in /usr/www/users/drew/scripts/admin/admin_img.php on line 31
Der Inhalt von $filename ist jedoch korrekt, das habe ich mir mittels echo ausgeben lassen.
Ich habe schon viel herumgesucht um diesem Fehler auf die Spur zu kommen, aber ich komme nicht auf den Fehler. Die Rechte in den Verzeichnissen sind richtig gesetzt (chmod 777), sonst hätte es ja auch in der ursprünglichen Variante nicht geklappt. Alles was ich getan habe ist, das Script in ein anderes Verzeichnis zu kopieren und die Pfade anzupassen. Daß der Pfad korrekt ist weiß ich mit Sicherheit, da mir das Directory korrekt angezeigt wird.
Der Upload klappt übrigens nach dem Verlegen des Scripts in das Adminverzeichnis auch nicht mehr.
Ein verzwicktes Problem. Weiß jemand Rat?
viele Grüße & danke im Voraus
DrDee :-)
-
Servus,
Warning: unlink(/usr/www/users/drew/scripts/uploads/) [function.unlink]: Operation not permitted in /usr/www/users/drew/scripts/admin/admin_img.php on line 31
Wie die Fehlermelduung doch eindeutig sagt fehlen dem Script die nötigen Rechte, um die Datei zu löschen. Setze diese entsprechend.
Ausserdem solltest du keine kompletten Pfade in Scripts verwenden. Der Änderungs-Aufwand bei Umzug des Scripts in ein anderes Verzeichnis (z.B. Server-Umzug) wäre enorm. Referenziere stattdessen relativ zum Root-Pfad der Anwendung. Letzteren definierst du in einer Konfigurationsdatei (als Konstante in PHP, in einem XML-Konfigurationsfile, ...).
Gruss
Patrick--
sh:( fo:| ch:? rl:( br:> n4:( ie:% mo:) va:} de:> zu:) fl:| ss:| ls:[ js:|-
Hallo!
Vielen Dank für Deine Antwort. Hättest Du einen Tipp für mich, wie es möglich ist, daß das Script die Rechte verloren hat? Es hat ja bereits funktioniert und ich habe es nur in ein anderes Verzeichnis kopiert.
Ja, das mit dem absoluten Pfad ist keine gute Sache. Ich habe das auch nur aus Verzweiflung getan, um den relativen Pfad als Fehlerquelle auszuschließen.
viele Grüße
DrDee :)
-
Servus,
[...] ich habe es nur in ein anderes Verzeichnis kopiert.
_Du_ hast das File kopiert. Dabei hast du (bzw. dein FTP/SCP/wasauchimmer-Programm) sehr wahrscheinlich die Rechte oder den Owner geändert.
Gruss
Patrick--
sh:( fo:| ch:? rl:( br:> n4:( ie:% mo:) va:} de:> zu:) fl:| ss:| ls:[ js:|-
Hi!
Ich habe mir nun einmal die Rechte der upgeloadeten Dateien angesehen und da steht als ownler für eine Datei die mittels script hochgeladen wurde "nobody" und als gruppe "bin". Ich weiß nicht wie das zustandekommt, jedenfalls ist das Script nicht berechtigt, diese Dateien zu löschen.
Und ich als user bin mittels FTP oder SSH-Client nicht berechtigt an diesen Dateien den Befehl CHMOD auszuführen. Aber ich kann sie löschen. Mir ist jedoch nicht ganz klar wie ich die Rechte des Scriptes setzen kann. Dazu reicht mein Unixwissen nicht aus.
viele Grüße
DrDee
-
Hello,
Und ich als user bin mittels FTP oder SSH-Client nicht berechtigt an diesen Dateien den Befehl CHMOD auszuführen. Aber ich kann sie löschen. Mir ist jedoch nicht ganz klar wie ich die Rechte des Scriptes setzen kann. Dazu reicht mein Unixwissen nicht aus.
Du guckst an der verkehrten Stelle.
Schau Dir die Rechte, Owner und Gruppe des Verzeichnisses an, in dem die Datei liegt.Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)
-
Hallo!
Das Verzeichnis in dem die Datei liegt habe ich ja selbst in FTP angelegt. Der owner bin ich und die Gruppe ist "user". Write - Read - und Execute in allen 3 Möglichkeiten sind auch gesetzt. Deshalb klappt auch der Upload. Aber nachdem etwas upgeloaded wurde ist das gerade hochgeladene File auf einmal gesperrt. Warum auch immer ...
viele Grüße
DrDee :)
-
Hello,
Das Verzeichnis in dem die Datei liegt habe ich ja selbst
das war Objekt 1, der User, der vor dem Client sitzt
in FTP angelegt.
das war Objekt 2, das Werkzeug und sein "Login-User"
Der owner bin ich
Das ist falsch, der Owner ist üblicherweise der User Deines FTP-Zuganges, also Dein "Login-User"
und die Gruppe ist "user".
Das ist nun schon wieder Objekt 3,
Write - Read - und Execute in allen 3 Möglichkeiten sind auch gesetzt.
Das ist bei vernünftiger Konfiguration des Servers nicht notwendig,
da würde dann rw- rw- --- auch genügen für Files
und für Verzeichnisse dann eben rwx rwx ---Deshalb klappt auch der Upload. Aber nachdem etwas upgeloaded wurde ist das gerade hochgeladene File auf einmal gesperrt. Warum auch immer ...
Der Upload per Script klappt deshalb, weil der HTTP-Server-User bzw. der Script-User (bei CGI) in dem _Verzeichnis_ Schreibrechte hat, in das das File _nach_ dem Upload verschoben wird und weil er Schreib- und Leserechte hat in dem Verzeichnis, in dem das File _während_ des Uploads zischengelagert wird.
Um Dir zu helfen, müssten wir also erst einmal wissen,
-
ob PHP bei Dir als Modul oder al CGI läuft
-
wer dann ggf. der Server-User ist und was seine primary group ist
-
wer dann ggf. der Script-User ist und was seine primary group ist
-
Wie dein FTP-User heipt und und was seine primary group ist
-
ob Du Einfluss auf irgeneine dieser Konfigurationen hast
-
ob die User auch noch supplemental Groups zugeornet sind. Das könnte dann nämlich ggf. die Lösung sein. Auf einem System mit PHP als Modul sollte der Server allen Supplemntal Groups seiner PHP-Kunden zugeordnet sein. Damit könnte man dann alles vernünftig regeln.
Da das bei einem ordentlichen Hoster auch bei shared Hosting nicht mehr als 200 sein sollten, bleibt es überschaubar.
Safe-Mode scheint ja zum Glück nicht auch noch aktiv zu sein.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)
-
-
-
-
-
-
-
-
Hallo nochmal!
Ich habe das Problem zwar noch nicht gelöst aber mir ist aufgefallen, daß der Upload doch funktioniert, jedoch nur dann, wenn das betreffende File noch nicht im Verzeichnis vorhanden ist. Jedenfalls sieht es momentan dannach aus, daß das der Grund sein könnte.
viele Grüße
DrDee