Bash/WCP: Löschen eigener Dateien nicht möglich

    Hallo @all,
    ich habe zu Testzwecken auf der Kommandozeile meines Webservers mittels scp ein Verzeichnis inkl. Subdirectories von einem anderen server in mein ~/tmp-Verzeichnis kopiert.
    Nach dem Ende des Tests wollte ich das komplette, runtergeladene Verzeichnis wieder löschen - darf ich aber nicht: "Permission denied"
    Dabei gehören mir (also dem User, der ichin der Bash bin) alle Dateien in dem Verzeichnis und ich habe auch rw-Rechte?
    Löschen funktioniert auch im WCP nicht - ich kann zwar andere Berechtigungen setzen - löschen darf ich die Datei aber nicht?
    Aber eine andere Datei, die ich mit wget geholt habe, konnte ich problemlos wieder löschen.

    Hat jemand von euch 'ne Idee, was da los sein könnte?

    Danke für eure Ideen,

    uli

    Bist du sicher, dass du der Besitzer bist?

    /tmp ist ja typischerweise root-owned und ge-stickybit-et.

    »Hauptsache BogoMIPS!«

    Fleischfresser

    »Sämtliche Cyberrisikomanagementmaßnahmen wurden übererfüllt!«

    Hi Olivetti,
    das ist korrekt. Das /tmp gehört root:root - alle anderen haben dort rwt - was nach meiner Lesart bewirkt, dass ich dort Verzeichnisse (und Unterverzeichnisse) anlegen darf und die mir auch gehören (ls -la zeigt auch meinen Nutzernamen und meine Grupe) - allerdings habe nur ich das Schreibrecht (und root natürlich *g*) und kann deshalb löschen - alle anderen (außer root) können nur lesen.
    Interessanterweise hat das mit 'ner anderen Datei, die ich nicht per scp, sondern per wget geholt und dort gespeichert hab erwartugnsgemäß funktioniert: Die konnte ich löschen, als ich sie nicht mehr gebraucht habe ...
    Was übersehe ich?

    Moin Tab,
    gute Idee! Allerdings gibt's lsattr in meiner Umgebung nicht. Ich hab mir deshalb die Originaldateien angesehen - die haben zwar e gesetzt, aber kein immutable (i)-Flag. Ich fänd's zwar sehr eigen, wenn das beim Kopieren via scp gesetzt würde - aber eine andere Erklärung gibt's ja fast nicht?
    Die Frage ist nur, wie werde ich die Dateien wieder los?

    Quote from UliDe

    […] rwt […]

    Bei rwt ist doch das Sticky Bit gesetzt? Die standardmäßigen Rechte wären rwxr-xr-x (0755) für Ordner und rw-r--r-- (0644) für Dateien. (Umrechner)


    Setze die Rechte doch zum Test einmal über SSH auf 0777, eventuell auch die des übergeordneten Ordners.


    Quote from UliDe

    Die Frage ist nur, wie werde ich die Dateien wieder los?

    Wenn es direkt über das WCP auch nicht klappt, würde ich mich beim Support melden. Was sollst Du denn sonst machen? Dann müssen die das halt löschen oder die Rechte korrigieren :)

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Edited 2 times, last by KB19 ().

    Like 1
    Quote from KB19

    eventuell auch die des übergeordneten Ordners.

    Was meinst du mit übergeordnet. Der übergeordnete zu tmp ist hier ja / mit 710 und owner hostingXXX:psaserv

    »Hauptsache BogoMIPS!«

    Fleischfresser

    »Sämtliche Cyberrisikomanagementmaßnahmen wurden übererfüllt!«

    Da sich andere Dateien/Verzeichnisse in deinem /tmp offenbar löschen lassen, muss es wohl entweder an deinem per SCP übertragenen Verzeichnis oder den darin enthaltenen Dateien liegen. Oder an der Übertragung per SCP. Wie sah denn der SCP Befehl aus, irgendwelche speziellen Optionen? Mit SCP von einem Webhosting in das /tmp eines anderen zu kopieren habe ich jetzt (heute) nicht probiert.


    Jedenfalls sehen bei meinen Webhostings die Rechte, Owner und Gruppe von /tmp genauso aus wie bei dir, das ist wohl auch normal mit dem sticky bit. Ich habe jetzt nur mal mit WinSCP ein Verzeichnis mit einer Datei drin vom PC in das Webhosting kopiert. Das liess sich danach über WinSCP auch wieder löschen und auch in der SSH-Konsole kann ich es löschen, jedenfalls per "rm -rf tmp" im Root-Verzeichnis. Per rm oder rmdir natürlich nicht, weil es ein Verzeichnis ist bzw das Verzeichnis auch nicht leer ist. Das ist aber völlig normal.


    Edit: Natürlich nicht "rm -rf tmp" sondern "rm -rf tmp/test" wobei tmp/test das von mir per WinSCP reingeschobene Verzeichnis ist. Das tmp zu löschen wäre wahrscheinlich schwierig ;) .

    Quote from Olivetti

    Was meinst du mit übergeordnet. Der übergeordnete zu tmp ist hier ja / mit 710 und owner hostingXXX:psaserv

    Im ersten Posting ist die Rede von ~/tmp und nicht von /tmp. Je nachdem was der virtuelle Homeordner ist, kann das überall liegen. Ich bin davon ausgegangen, dass es um einen selbst erstellten Ordner mit dem Namen "tmp" geht. Wenn das nicht so ist, ignoriert meinen Beitrag bitte. Dann macht das Sticky-Bit natürlich Sinn und man kann es sowieso nicht entfernen.


    Generell wäre die vollständige Ausgabe von ls -la des betroffenen Unter-/Ordners hilfreich. (Inkl. den Ausgabezeilen für . und ..!)

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Edited once, last by KB19 ().

    Okay - erstmal danke für euer Hirnschmalz!
    KB19 - tatsächlich ist es /tmp - allerdings sind wir beim Webhosting ja in einer chrooted Umgebung, so dass das irgendwie ja auch ~/tmp ist. War aber mein Fehler, das nicht völlig klar angegeben zu haben. Deshalb ist das mit dem Sticky-Bit ja durchaus sinnvoll, damit das Verzeichnis nicht nur root zur Verfügung steht.
    Du hast aber den entscheidenden Tipp gegeben: "Setz doch mal die Rechte auf 777" - das war die Lösung: chmod -R a+rwx und danach ging auch ein rm -rf /tmp/<Verzeichnis>

    Warum das funktioniert hat, versteh ich zwar nicht, denn für den User hat sich ja rechtemäßig gar nichts geändert - aber damit ging's.

    Die Dateien sind weg und mein Webspace um 20 GB leichter. :)
    Danke nochmal für eure Tipps!

    Mich wundert gerade eher, wieso Du die Rechte dieses Ordners überhaupt ändern konntest. Oder gehört der nicht "root"? :/

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Stimmt, der gehört root, alle anderen haben dort rwt. Deshalb darf man auch als nicht root und mit 'ner anderen Gruppenzugehörigkeit dort schreiben und die Dateien gehören einem dann auch (ls -la hat meinen user und meine Gruppe als Eigentümer agezeigt).
    Löschen durfte ich sie nicht direkt. aber nachdem ich 777 als Rechte gesetzt hatte (das durfte ich paradoxerweise), konnte ich Dateien und Verzeichnisse löschen ...

    Wie gesagt - ich versteh's nicht, denn für den User war ja auch vorher 77 gesetzt. Ob da die Welt auch schreiben darf, sollte den nicht interessieren.
    Aber nach der Änderung gings ...

    Wenn du da irgendwann mal über 'ne Erklärung stolperst, freu ich mich über 'ne erhellende Info :)