Probleme mit Dateien löschen unter Sequoia

[Byteschön]

Verstehe dich jetzt nicht, die Ergebnisse aus dem Terminal um die Du gebeten hast habe ich doch oben gepostet....

Das bringt nix. Es muss doch die Datei sein, die du nicht vom Desktop löschen kannst. Also bitte nochmals.

Und zusätzlich bitte:

ls -led ~/.Trash

Frage:

Bist du mit dem Account angemeldet der namexxx ist? Ist dieser Account Admin oder Standarduser?

Okay, sorry, da habe ich vergessen, dass ~ nicht aufgelöst wird.

Also bitte folgendes tun

ls -leO ~"/Desktop/Dateiname"

Vielleicht habe ich mich undeutlich audgedrückt. Es existiert nicht "die" eine Datei, die sich nicht löschen lässt. Es sind alle Dateien betroffen, die ich auf dem Desktop ablege und wieder löschen möchte.

1. Löschbefehl für eine Datei
2. Es erscheint die Passwortabfrage, in der ich das PW eingebe und bestätige.
3. Es ist das Geräusch des Papierkorbs zu hören, die Datei liegt noch auf dem Desktop
4. Versuche ich die Datei, die noch auf dem Desktop zu sehen ist erneut zu löschen, erhalte ich die Fehlermeldung:

Gebe ich nun im Terminal den Befehl:

ls -led ~/.Trash

ein, erhalte ich das Ergebnis:

drwx------@ 10 namexxx staff 320 29 Mai 10:46 /Users/namexxx/Desktop<br> 0: group:everyone deny delete

5. Wenn ich anschliessend über Programme beenden den Finder beende ist auch der Papierkorb geleert.

Dachte ich habe alle Fragen beantwortet. Was benötigst Du noch? Vielleicht habe ich etwas übersehen oder nicht ganz verstanden.

 

[lisanet]

Vielleicht habe ich mich undeutlich audgedrückt. Es existiert nicht "die" eine Datei, die sich nicht löschen lässt. Es sind alle Dateien betroffen, die ich auf dem Desktop ablege und wieder löschen möchte.

Vielleicht habe ich mich undeutlcih ausgedrückt

Ich muss die Rechte einer derartigen datei sehen!!!!!!

Deine Aussage, dass alle dAtei betroffen sind, sagt mir nicht welche Rechte so eine Datei hat.

Gebe ich nun im Terminal den Befehl:

ls -led ~/.Trash
ein, erhalte ich das Ergebnis:

drwx------@ 10 namexxx staff 320 29 Mai 10:46 /Users/namexxx/Desktop<br> 0: group:everyone deny delete

Ich glaube dir nicht, dass das die Ausgabe ist.

Bitte poste die KOMPLETTE EIN- UND AUSGABE des Befehls, damit ich das sehen kann. In Code-Tags.

Wenn's wieder nicht kommt, dann bin ich raus. Definitiv. Ich habe keine Lust, mich andauernd zu wiederholen.

Edit:

Und die Frage nach iCloud aus #13 ist auch nicht beantwortet.

Aber ich gehe jetzt eh erst mal Essen. Vielleicht heute spät abend nochmals oder dann morgen oder so. Viel Glück.

 

[Byteschön]

War es mal genutzt, vielleicht irrtümlich bei der Installation? Das hatte ich auch gefragt.

Jetzt wo Du fragst, fällt mir noch ein, dass ich zu Beginn, also nach der frischen Installation, Drive laut Apple-Support einschalten soll bis sich Timemachine "aktiviert" hat. Ich hatte den Support kontaktiert, weil sich TM nicht starten ließ. Das erledigt sich nach 2-3 Tagen nach der Installation von selbst, so der Support. So war es auch, danach abe ich es deaktiviert.

 

[Byteschön]

Also hier noch mal die Eingabe sowie das Ergebnis im Terminal: (benutzername@computername wieder geändert)

Last login: Thu May 29 15:58:03 on ttys000
namexxx@computername ~ % ls -led ~/.Trash
drwx------+ 67 root  staff  2144 29 Mai 16:49 /Users/musicmac/.Trash
 0: group:everyone deny delete
namexxx@computername ~ %

 

[Byteschön]

Vielleicht habe ich mich undeutlcih ausgedrückt

Ich muss die Rechte einer derartigen datei sehen!!!!!!

Deine Aussage, dass alle dAtei betroffen sind, sagt mir nicht welche Rechte so eine Datei hat.



Ich glaube dir nicht, dass das die Ausgabe ist.

Bitte poste die KOMPLETTE EIN- UND AUSGABE des Befehls, damit ich das sehen kann. In Code-Tags.

Wenn's wieder nicht kommt, dann bin ich raus. Definitiv. Ich habe keine Lust, mich andauernd zu wiederholen.

Edit:

Und die Frage nach iCloud aus #13 ist auch nicht beantwortet.

Aber ich gehe jetzt eh erst mal Essen. Vielleicht heute spät abend nochmals oder dann morgen oder so. Viel Glück.

Vielen Dank für deine Zeit und guten Appetit,

 

[lisanet]

Also hier noch mal die Eingabe sowie das Ergebnis im Terminal: (benutzername@computername wieder geändert)

Last login: Thu May 29 15:58:03 on ttys000
namexxx@computername ~ % ls -led ~/.Trash
drwx------+ 67 root  staff  2144 29 Mai 16:49 /Users/musicmac/.Trash
 0: group:everyone deny delete
namexxx@computername ~ %

bin gerade angekommen und habe nochmal schnell hier nachgeschaut.

Das ist das Problem. Der Papierkorb hat falsche Rechte und gehört nicht deinem Account.

Ich bin gerade nur am iPhone und kann es daher am Mac nicht kontrollieren. Aber es sollte wie folgt gehen.

Wenn dein accountnsme musicmac ist, dann mach bitte folgendes. Andernfalls musst du deinen Account Namen eben richtig einsetzen.

sudo chown musicmac ~/.Trash

und dein Admin PW eingeben.

Das sollte das Problem lösen

 

[Byteschön]

Wow, das ist ja super, die Dateien lassen sich wieder wie gewohnt löschen !!!! Vielen Dank

 

[Byteschön]

Das gibt es ja gar nicht, jetzt ist das Thema wieder da, mit dem ich mich an den Apple Support gewendet habe:

Grund war ein Ordner, welcher im Papierkorb lag und nicht gelöscht werden konnte. Dieser Ordner hat Unterverzeichnisse, die nur dann zu sehen, sind, wenn man die verstecken Dateien sichtbar macht. Versuche ich den Papierkorb zu leeren, erscheint folgendes:

Anhang anzeigen 461701

Klicke ich Forfahren erscheint folgendes:

Anhang anzeigen 461703

Klicke ich erneut Fortfahren, erscheint folgendes:

Anhang anzeigen 461705

Klicke ich erneut Fortfahren, erscheint folgendes:

Anhang anzeigen 461709
(Ist der Ordner der im Papierkorb sichtbar ist, diesen hatte ich mal umbenannt, deshalb der seltsame Name)

Klicke ich erneut Fortfahren, erscheint folgendes:

Anhang anzeigen 461707

So wie ich das sehe, versucht das OS die Verzeichnisse von Innen nach außen zu löschen, was jedoch aufgrund von nicht erforderlichen Zugriffsrechten nicht ging.

So wie es aussieht hat mir der Support einen "neuen" Papierkorb eingerichtet, der nicht zum Benutzer gehört. Deshalb war das ursprüngliche Problem nicht mehr sichtbar, jedoch das Rechteproblem von Dateien auf dem Desktop vorhanden. Nun hast Du mir gerholfen, den richtigen Papierkorb wieder zu aktivieren. Das Problem mit dem Ordner im Papierkorb wurde somit vom Support nicht gelöst, sondern für mich einfach nur "unsichtbar" gemacht.

Jetzt bin ich genau so weit wie vor einer Woche.

Ich kann alle Dateien vom Desktop oder sonst wo wieder in den Papierkorb bewegen und löschen. Nur dieser eine Ordner im Papierkorb lässt sich nicht entfernen.

Tendiere gerade in die Richtung schleche Noten für den Support zu vergeben, wenn dieser das Problem nicht löst, sondern dem für den User einfach unsichtbar macht.

 

[lisanet]

Ich kann alle Dateien vom Desktop oder sonst wo wieder in den Papierkorb bewegen und löschen. Nur dieser eine Ordner im Papierkorb lässt sich nicht entfernen.

Das lässt sich lösen. Das machen wir morgen, okay?

Tendiere gerade in die Richtung schleche Noten für den Support zu vergeben, wenn dieser das Problem nicht löst, sondern dem für den User einfach unsichtbar macht.

Tja, auch dort sitzen mal Menschen, die mit dem Job erst anfangen. Und vergiss nicht, wie lange wir hier nun gebraucht haben, bis ich die passenden Infos erhalten habe. Erfolgreicher IT-Support hängt immer von beiden Seiten ab. Ich will damit nicht Apple verteidigen, sondern Verständnis erzeugen, dass es immer multi-kausale Ursachen gibt.

 

[Byteschön]

Ja, sicher habe ich dafür Verständnis, machen auch nur Ihren Job. Sehr gerne machen wir morgen weiter. Nochmals herzlichen Dank an dieser Stelle für deine Zeit.

 

[lisanet]

Sehr gerne machen wir morgen weiter.

So, ....

die Anhänge sind leider nicht mehr sichtbar. (geht aber auch ohne).

Damit ich einen Überblick habe, obwohl ich schon was vermute, mache bitte im Terminal mal folgendes und poste Eingabe und Ausgabe komplett bitte. In code-Tags. Jeden Zeile einzeln!

Erst mal eine Übersicht für mich:

cd ~/.Trash
ls -ledO

Nun der interessante Teil.

Das Herausfordernde ist hier, dass die Ausgabe auch extrem lang werden kann. Ich habe daher den Befehl so gestaltet, dass er dass alles zusammenfasst. Dadurch ist er aber sehr lang. Am besten du gibst den 2. Befehl (den mit ls) per copy&paste ein.

cd ~/.Trash
ls -leRO | grep -o -e restr -e schg -e uchg -e simmu -e uimmu | sort | uniq

O ist der Buchstabe.

Wie gesagt jeden Befehl einzeln eingeben.

Einen "pauschalen" Versuch kann bzw will ich dir nicht nennen, da ich den genauen Namen des nicht löschbaren Verzeichnisses nicht kenne. Also bitte erst mal die beiden obigen Ein- und Ausgaben.

PS: ich bin heute aber ab ca. Mittag weg

 

[Byteschön]

So, ....

die Anhänge sind leider nicht mehr sichtbar. (geht aber auch ohne).

Damit ich einen Überblick habe, obwohl ich schon was vermute, mache bitte im Terminal mal folgendes und poste Eingabe und Ausgabe komplett bitte. In code-Tags. Jeden Zeile einzeln!

Erst mal eine Übersicht für mich:

cd ~/.Trash
ls -ledO

Nun der interessante Teil.

Das Herausfordernde ist hier, dass die Ausgabe auch extrem lang werden kann. Ich habe daher den Befehl so gestaltet, dass er dass alles zusammenfasst. Dadurch ist er aber sehr lang. Am besten du gibst den 2. Befehl (den mit ls) per copy&paste ein.

cd ~/.Trash
ls -leRO | grep -o -e restr -e schg -e uchg -e simmu -e uimmu | sort | uniq

O ist der Buchstabe.

Wie gesagt jeden Befehl einzeln eingeben.

Einen "pauschalen" Versuch kann bzw will ich dir nicht nennen, da ich den genauen Namen des nicht löschbaren Verzeichnisses nicht kenne. Also bitte erst mal die beiden obigen Ein- und Ausgaben.

PS: ich bin heute aber ab ca. Mittag weg

Hallo, vielen Dank fürs Weitermachen:

OK, hier das Ergebnis zum ersten Codeabschnitt: (Eingabe+Enter)

Last login: Fri May 30 11:40:33 on console
namexxx@benutzername ~ % cd ~/.Trash
namexxx@benutzername .Trash % ls -ledO
drwx------+ 3 musicmac  staff  - 96 29 Mai 17:45 .
 0: group:everyone deny delete
namexxx@benutzername .Trash %

Hier das Ergebnis für den zweiten Abschnitt: (Eingabe+Enter)

Last login: Fri May 30 11:42:21 on ttys000
namexxx@benutzername ~ % cd ~/.Trash
mnamexxx@benutzername .Trash % ls -leRO | grep -o -e restr -e schg -e uchg -e simmu -e uimmu | sort | uniq
namexxx@benutzername .Trash %

Schließe ich das Terminal, öffne es erneut und gebe nur den zweiten Befehl ein, erhalte ich folgendes Ergebnis:

Last login: Fri May 30 11:45:59 on ttys000
namexxx@benutzername ~ % ls -leRO | grep -o -e restr -e schg -e uchg -e simmu -e uimmu | sort | uniq
ls: ./Library/Caches/2BUA8C4S2C.com.agilebits.onepassword4-helper/WebKit/NetworkCache/Version 17: Permission denied
ls: ./Library/Caches/com.apple.logic10/WebKit/NetworkCache/Version 17: Permission denied
ls: ./Library/Caches/com.apple.parsecd/Cohorts: Permission denied
ls: ./Library/Caches/com.apple.parsecd/CustomFeedback: Permission denied
ls: ./Library/Caches/com.apple.Safari/WebKitCache/Version 17: Permission denied
ls: ./Library/Caches/com.bombich.ccc/WebKit/NetworkCache/Version 17: Permission denied
ls: ./Library/Caches/com.spitfireaudio.Labs/WebKit/NetworkCache/Version 17: Permission denied
ls: ./Library/Caches/GameKit/StoreBag: Permission denied
ls: fts_read: Permission denied
restr
namexxx@benutzername ~ %

Was ich noch im festgestellthabe ist, dass im Verzeichnis Benutzer/Geteilt/ folgende Verzeichnisse angelegt sind:

Previously Relocated Items (Mit Apple-PDF Info: Was sind neu zugewiesene Objekte?)
Previously Relocated Items 1
Previously Relocated Items 2
Previously Relocated Items 3
Previously Relocated Items 4
Zuvor Bewegte Objekte

Kann das mit dem Problem der Zugrissfrechte zusammenhängen?

 

[Byteschön]

Das gibt es ja gar nicht, jetzt ist das Thema wieder da, mit dem ich mich an den Apple Support gewendet habe:

Grund war ein Ordner, welcher im Papierkorb lag und nicht gelöscht werden konnte. Dieser Ordner hat Unterverzeichnisse, die nur dann zu sehen, sind, wenn man die verstecken Dateien sichtbar macht. Versuche ich den Papierkorb zu leeren, erscheint folgendes:

Anhang anzeigen 461701

Klicke ich Forfahren erscheint folgendes:

Anhang anzeigen 461703

Klicke ich erneut Fortfahren, erscheint folgendes:

Anhang anzeigen 461705

Klicke ich erneut Fortfahren, erscheint folgendes:

Anhang anzeigen 461709
(Ist der Ordner der im Papierkorb sichtbar ist, diesen hatte ich mal umbenannt, deshalb der seltsame Name)

Klicke ich erneut Fortfahren, erscheint folgendes:

Anhang anzeigen 461707

So wie ich das sehe, versucht das OS die Verzeichnisse von Innen nach außen zu löschen, was jedoch aufgrund von nicht erforderlichen Zugriffsrechten nicht ging.

So wie es aussieht hat mir der Support einen "neuen" Papierkorb eingerichtet, der nicht zum Benutzer gehört. Deshalb war das ursprüngliche Problem nicht mehr sichtbar, jedoch das Rechteproblem von Dateien auf dem Desktop vorhanden. Nun hast Du mir gerholfen, den richtigen Papierkorb wieder zu aktivieren. Das Problem mit dem Ordner im Papierkorb wurde somit vom Support nicht gelöst, sondern für mich einfach nur "unsichtbar" gemacht.

Jetzt bin ich genau so weit wie vor einer Woche.

Ich kann alle Dateien vom Desktop oder sonst wo wieder in den Papierkorb bewegen und löschen. Nur dieser eine Ordner im Papierkorb lässt sich nicht entfernen.

Tendiere gerade in die Richtung schleche Noten für den Support zu vergeben, wenn dieser das Problem nicht löst, sondern dem für den User einfach unsichtbar macht.

Hier noch mal die fehlenden Anhänge:

Reihenfolge der Anhänge zeigt die (versteckten) Verzeichnisse von innen nach aussen

Sichtbares Verzeichnis im Papierkorb

 

[Byteschön]

Ich habe gerade versucht über einen Downloadmanager ein Update zu laden, funktioniert jedoch nicht. darauf hin habe ich einen zweiten Downloadmanager eines anderen Programmes geöffnet. Dieser fragt ständig nach dem Verzeichnis, in dem die Daten abgelegt sind. Obwohl dies vorhanden ist, erscheint die Meldung stets erneut. Gestern konnte ich ein Update für Logic Pro im Appstore nur über einen anderen Benutzer downloaden, in diesem "Haupt"-Benutzer drehte sich der Kreis im Appstore endlos, vom anderen Benutzer startete der DL sofort.

Kann es sein, dass die Thematik der Zugriffsrechte doch größer ist als nur auf dem Papierkorb bezogen? Ich habe langsam den Verdacht, dass das gesamte Benutzerprofil insgesamt ein Problem mit Lese- und Schreibrechten hat.

Wenn Donwloads nicht starten oder Programme stets nach dem gleichen Verzeichnis fragen, in dem bereits Daten abgelegt sieht das mit meinem Laienverständnis danach aus, dass die Zugriffe nicht (sauber) funktionieren.

Das lief m.E. jedoch alles bis zum Kontakt mit dem Apple-Support, da ich in den letzten Wochen eine Reihe von Aktualisierungen unterschiedlicher Programme gemacht habe.

 

[lisanet]

oh Mann, wenn ich das alles so lese: Hauptbenutzer, Library ist in Verwendung, Mobile Documents ist in Verwendung, und in deinen anderen Threads machst du viel mit OCLP rum, dann kann ich dir übers Forum hier nicht mehr weiterhelfen. Wenn ich vom Rechner sitzen würde, würde es gehen, so aber nicht. Sorry.

Es sieht für mich so aus, dass du von einer deiner externen Festplatten, einen kompletten Benutzer Account in den Papierkorb geworfen hast. Das ist mit einer der dümmsten Ideen. Da sind dir nun im Weg sowohl die Unix-Rechte, verschiedene ACL und auch flags, insbesondere in der Library, die Löschen verhindern sollen. Das macht in der Library sehr viel Sinn. Und gegen all das müsstest du nun vorgehen.

ich kann dir daher nur empfehlen, dass du in deiner Nähe versuchst, einen Mac Club zu finden. Vielleicht ist da jemand, der sich auskennt und der sich an deinen Rechner setzen kann. Oder du besorgst dir einen professionellen Dienstleister. Aber über ein Forum wird das nichts. Sorry

 

[Schiffversenker]

Ich habe gerade versucht über einen Downloadmanager ein Update zu laden, funktioniert jedoch nicht.

Bei welchem Programm oder System braucht man dafür ein Hilfsprogramm?

darauf hin habe ich einen zweiten Downloadmanager eines anderen Programmes geöffnet.

Welche Programme haben denn „Downloadmanager“?

 

[Bachsau]

Es sieht für mich so aus, dass du von einer deiner externen Festplatten, einen kompletten Benutzer Account in den Papierkorb geworfen hast.

Wenn man Dateien von externen Festplatten in den Papierkorb wirft, werden die nicht auf das System-Volume kopiert, sondern in ein ".Trashes"-Verzeichnis auf der jeweiligen Platte verschoben.

Die "Previously Relocated Items N" enthalten Sicherungskopien von Dateien aus System-Verzeichnissen, die vor dem Update verändert waren. In der Regel lassen sie sich problemlos löschen. Bei älteren macOS-Versionen waren sie aber teils fälschlicherweise vom Systemdatei-Schutz erfasst. In diesem Fall lassen sie sich nur aus dem Recovery-OS heraus löschen.

Was das Reparieren eines widerspenstigen Papierkorbs angeht:

sudo rm -rf .Trash

Da braucht man nicht anfangen, an Zugriffsrechten herumzubasteln, sondern man löscht ihn einfach. macOS erstellt das Verzeichnis neu, sobald wieder eine Datei gelöscht wird. Sollte auch dieser Befehl nicht funktionieren, haben wir es wieder mit dem Systemdatei-Schutz zu tun. In diesem Fall ins Recovery-OS booten, und das Ganze nochmal. ACHTUNG: Vorher System-Volume aktivieren und ins richtige Verzeichnis wechseln!

Kann es sein, dass die Thematik der Zugriffsrechte doch größer ist als nur auf dem Papierkorb bezogen? Ich habe langsam den Verdacht, dass das gesamte Benutzerprofil insgesamt ein Problem mit Lese- und Schreibrechten hat.

Kann es, wobei sich hier die Frage stellt, wie es dazu gekommen ist.

Man kann mit

sudo diskutil resetUserPermissions / `id -u`

eine Reparatur versuchen. Wenn das nichts bringt, geht's auch manuell, aber das ist zu komplex, um es jemandem zu beschreiben, der keine Ahnung hat.

 

[lisanet]

Da braucht man nicht anfangen, an Zugriffsrechten herumzubasteln, sondern man löscht ihn einfach. macOS erstellt das Verzeichnis neu, sobald wieder eine Datei gelöscht wird. Sollte auch dieser Befehl nicht funktionieren, haben wir es wieder mit dem Systemdatei-Schutz zu tun. In diesem Fall ins Recovery-OS booten, und das Ganze nochmal. ACHTUNG: Vorher System-Volume aktivieren und ins richtige Verzeichnis wechseln!

Das weiß ich alles.

Aber einem User einfach mal ein rm -rf anzubieten, der keine Ahnung hat, wie er sich im Terminal zu bewegen hat und dann als Alternative auch noch via Recovery vorbei an SIP zu gehen, ist schon gewagt. Und insbesondere finde ich dein "Achtung" schon ein klein wenig fahrlässig.

Wenn du ihm das Schritt für Schritt beschreiben willst bitte schön. Ich mach sowas nicht, da es in der Vergangenheit immer zu Problemen geführt hat.

Im Übrigen hat es nicht nur was mit SIP zu tun, sondern halt auch mit anderen flags.

 

[Bachsau]

Klar, ist aber der einzige Weg, wie man das Problem in den Griff bekommen kann. Wie es dazu gekommen ist, muss er schon selbst wissen, ebenso, ob er sich den Umgang mit diesen Terminal-Befehlen zutraut. Ich geh davon aus, dass ich es mit einem erwachsenen Menschen zu tun habe. Im Zweifel muss er die Kiste halt in erfahrenere Hände geben.

 

[lisanet]

Klar, ist aber der einzige Weg, wie man das Problem in den Griff bekommen kann.

Nein, ist es nicht.

Ein Löschen der jeweilgen flags und ACL im betroffenen Papierkorb, nachdem man den Owner geändert hat, reicht aus, wenn es sich tatsächlich um ein User-Home handelt. Ich wusste kein Verzeichnis im User-Home das ein restricted flag hätte.