Unexpected Error. (-5000) on file: xxx

[peters1]

Ein frohes Neues!
Ich versuche mit SetFile ein Datum einer Datei zu ändern. Ich bekomme aber nur den Fehler

Unexpected Error. (-5000) on file: xxx

Das weist auf mangelnde Zugriffsrechte hin. Mit dem aktuellen User bin ich Admin. Das Verzeichnis und die Datei haben für diesen User Schreib-/Lesezugriff, habe ich überprüft und noch einmal überbügelt. Dazu Reboot.

Was habe ich übersehen?
Viele Grüße
Dirk

Befehl bspw:
SetFile -d '02/08/2020 18:40:30' '/Volumes/Meins/Fotos/2020/2020_02_08_09_Lachende_Koelnarena/_ORG/IMG_280000_2020.02.08-18.40.30_iPhone8_1920x1080p60fps42s.MOV'

 

[Marcel Bresink]

Das weist auf mangelnde Zugriffsrechte hin.

Nein, wie kommst Du darauf?

Die wahrscheinlichste Ursache dürfte sein, dass Dein Datenträger "Meins" ein Dateiformat verwendet, das die Angabe "Erstellungsdatum" nicht unterstützt.

"Erstellungsdatum" ist ein ziemlich exotisches Attribut, das es früher mal im klassischen Mac OS gab und von Carbon-Programmen aus zugreifbar war. Aus Kompatibilitätsgründen wird es manchmal noch unterstützt, aber darauf kann man sich nicht verlassen.

Verlässlich wird nur das Datum der letzten Änderung und des letzten Zugriffs gespeichert. Das kann man mit dem Unix-Befehl "touch" ändern.

 

[peters1]

Die Platte ist
"Mac OS Extended (journaled)"
formatiert. Hat früher auch genau so funktioniert.
Touch hat den Nachteil, dass man keine in der Vergangenheit liegende Datumwerte setzen kann. Mit SetFile geht/ging beides.

 

[Marcel Bresink]

Touch hat den Nachteil, dass man keine in der Vergangenheit liegende Datumwerte setzen kann.

Das stimmt nicht. Man kann beliebige Werte setzen.

 

[peters1]

Das habe ich aus einer Doku:

AFP Protocol Errors
afpAccessDenied = -5000, /* Insufficient access privileges for operation */

Das stimmt nicht. Man kann beliebige Werte setzen.

Ich hatte es ausprobiert, allerdings vor ein paar Jahren. Man konnte kein Datum setzen, das vor dem aktuell gesetzten Erstellungsdatum liegt. Und das habe ich auch dokumentiert im Netz gefunden, inkl. Workaround.

Hier ist auch ein Link dazu:
https://apple.stackexchange.com/questions/99536/changing-creation-date-of-a-file

 

[Marcel Bresink]

Das habe ich aus einer Doku:

OK, aber dieser Fehlercode wäre nur anwendbar, wenn die Datei nicht auf einer Platte, sondern auf einem File Server mit dem alten AFP-Protokoll liegen würde.

Man konnte kein Datum setzen, das vor dem aktuell gesetzten Erstellungsdatum liegt.

Doch, das ging schon immer. Aber man muss natürlich die üblichen Angaben Zugriffsdatum oder Änderungsdatum verwenden.

Der Link beschäftigt sich hauptsächlich mit der Frage, ob es irgendwelche Tricks gibt, damit der Mac indirekt auch das (für touch nicht existente) Erstellungsdatum ändert, wenn man das Änderungsdatum überschreibt.

 

[peters1]

OK, verstanden.

Was wäre der Tipp? Ich muss das Erstellungsdatum setzen. Bislang lief es mit "SetFile" jahrelang. Weiss leider nicht, wann zuletzt erfolgreich. OSX-Update?

Und wo kann ich die Meldung -5000 in Klarschrift finden?

 

[MacAlzenau]

Disk Utility - Error 5000 - Apple Community

discussions.apple.com

MAC OS Error code -5000 - Apple Community

discussions.apple.com

Simple tips to repair error code 5000 for your Mac

(und sicher auch andere) beschäftigen sich mit der Frage was der Code bedeutet und (vor allem der dritte Link) was man dagegen machen kann.
Ist wohl kein sehr spezifischer Code, umfasst etliche Möglichkeiten:

The followings are the main causes why your Mac gets error messages:

• Improper operations on the system, application, process or service
• Corrupted system files and directories, misconfigured system settings
• Virus infection, malware or spyware attacks, suspicious file download
• Incompatible or outdated software/hardware installed on the machine
• Junk files filled with the startup drive or current user’s home directory

Ich nehme mal an, daß sich das nicht pauschal auf Fehlermeldungen bezieht, sondern auf diese -5000.

Die Seite fixmacissue.com sehe ich allerdings skeptisch, da sie einem gleich ein Rettungsprogramm empfiehlt. Da sollte man sehr vorsichtig sein, vor allem wenn da ein "Optimizier" im Namen steckt.

Wenn die Fehlermeldung allerdings nur kommt, wenn du SetFile benutzt , würde ich Richtung "incompatible or outdated software" tippen. Also schauen, ob es davon eine neuere Version gibt, oder halt touch benutzen.
Zur Anwendung im Terminal man touch eingeben, da bekommt man detailliert beschrieben, was alles möglich ist. Zu verbreiteten UNIX-Kommandos gibt es üblicherweise auch Hilfeseiten bei Apple oder sonstwo im Netz.

 

[peters1]

Ich habe eine Lösung gefunden:
Mit dem su geht es. Dazu musste ich erst (bei aktuell 10.15.6) den root-User freischalten. Der wurde wohl bei irgendeinem OSX-Update gesperrt, ausgelagert etc - was weiss ich. Nach der Freischaltung konnte ich mich im Terminal als su einloggen und dann den Befehl ausführen. Fehlerfrei.
=> Da sind irgendwelche Zugriffsbeschränkungen für den aktuellen (Admin-)User. Angezeigt bekomme ich - wie beschrieben - dass der Admin-User Lesen/Schreiben darf.

Wenn ich die Datei im gleichen Verzeichnis dupliziere, dann geht es auch mit dem aktuellen User auf dieser Kopie. => irgendetwas im Hintergund hat sich da eingenistet. Ich werde also alle Dateien kopieren und dann diese Kopie nutzen, damit meine Zugriffsrechte wieder sauber sind.

Danke für den Support.

@MacAlzenau:
Bei touch ist es der gleiche Fehler, ich habe die XCode-Support-Files (mit SetFile) aktualisiert, das war's auch nicht. Touch hatte ich vor Jahren im Einsatz, d.h. ich kenne dessen Funktionen, nur der Workaround, eine Datei erst kopieren zu müssen, um deren Create date anzupassen, war mir zu zeitraubend. Daher der Griff zu SetFile.

 

[Marcel Bresink]

Mit dem su geht es.

Das würde darauf hindeuten, dass Berechtigungen oder Attribute an Ordner oder Datei falsch eingestellt waren. Hast Du die nur mit dem Finder angezeigt?

Dazu musste ich erst (bei aktuell 10.15.6) den root-User freischalten.

Das ist hochgefährlich und unnötig. Wenn es mit su geht, reicht es völlig, dem SetFile-Programm ein "sudo" voranzustellen. Der root-User sollte schnellstmöglich wieder zur Anmeldung gesperrt werden.

Was liefert der Befehl

ls -lOe@ /Volumes/Meins/Fotos/2020/2020_02_08_09_Lachende_Koelnarena/_ORG/IMG_280000_2020.02.08-18.40.30_iPhone8_1920x1080p60fps42s.MOV

?

 

[peters1]

Das Ergebnis ist:

-rw-------@ 1 dirk  staff  - 62254397 20 Feb  2020 /Volumes/Meins/Fotos/2020/2020_02_08_09_Lachende_Koelnarena/_ORG/IMG_280000_2020.02.08-18.40.30_iPhone8_1920x1080p60fps42s.MOV
    com.apple.metadata:_kMDItemUserTags          51
0: group:Admins allow read,write,append,readattr,writeattr,readextattr,writeextattr,readsecurity
1: group:admin allow read,write,append,readattr,writeattr,readextattr,writeextattr,readsecurity
2: user:serveruser allow read,write,append,readattr,writeattr,readextattr,writeextattr,readsecurity
3: user:petra allow read,write,append,readattr,writeattr,readextattr,writeextattr,readsecurity

Serveruser ist derjeinge, in dessen Context der Befehl ausgeführt wurde.

 

[Marcel Bresink]

Da wurden die normalen Berechtigungen ja ganz erheblich geändert. Allgemeines Leserecht und Rechte für die Standardbenutzergruppe "staff" wurden gesperrt. Stattdessen wurden zusätzliche Zugriffssteuerungseinträge eingerichtet.

Ist für dieses Volume die Funktion "Eigentümer auf diesem Volume ignorieren" im Finder eingeschaltet? Wie lauten die Rechte für den umschließenden Ordner?

ls -ldOe@ /Volumes/Meins/Fotos/2020/2020_02_08_09_Lachende_Koelnarena/_ORG/

 

[peters1]

Ja, das ist ein freigegebenes Laufwerk. Daher die Einschränkungen. "Eigentümer ignorieren" ist nicht gesetzt, damit die hier vergebenen Rechte auch wirken.
Der Serveruser ist aber der lokale User, der lokal auf die extern angeschlossene Platte zugreift.

Das Ergbenis ist:

drwx------+ 41 dirk  staff  - 1394  4 Jan 11:09 /Volumes/Meins/Fotos/2020/2020_02_08_09_Lachende_Koelnarena/_ORG/
0: group:Admins allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity
1: group:admin allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity
2: user:serveruser allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity
3: user:petra allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity

 

[Marcel Bresink]

OK, ich habe das überprüft:

Schreibrecht auf den Ordner oder die Datei reichen nicht aus, um eine Zeitangabe nachträglich ändern zu dürfen. Die Norm IEEE 1003.1-2017, bzw. der Industriestandard "Single UNIX Specification, Version 3" schreiben vor, dass die Verwendung von Funktionen, die die Zeitangaben eines Dateisystemobjekts ändern, nur einem privilegierten Prozess (sudo) oder einem Prozess erlaubt ist, dessen effektive Benutzer-ID dem Eigentümer des Objekts entspricht. ("Only a process with the effective user ID equal to the user ID of the file or with appropriate privileges may use…")

Mit anderen Worten: In diesem konkreten Fall dürfen nur "dirk" oder ein sudo-Prozess die Zeitattribute ändern. Die Berechtigungseinstellungen haben (außer der Eigentümerangabe) keinerlei Bedeutung.

Wenn das früher trotzdem ging, war das ein Sicherheits-Bug, der von Apple inzwischen behoben wurde.

 

[peters1]

Wow, dass das so kompliziert ist, hätte ich nicht gedacht! Respekt!
D.h. entweder ich ändere den Eigentümer aller Dateien auf "Serveruser" oder ich muss jedesmal ein "sodu" mit Passwort davorstellen.
Ich denke letzteres ist sauberer.
Danke für die viele Mühe und die perfekte Erklärung!