Was für ein Drama mal wieder. Nach Jahren treuer Dienste funktioniert plötzlich mein Raspberry Pi 3 B+ nicht mehr. Ich stele fest das die LAN Verbindung nicht mehr leuchtet. Dann fällt mir auf, das die ACT LED nix mehr macht.
Sofort schreibe ich auf eine andere SD-Karte ein Raspi-OS-Image, nix, die ACT (Drive-Activitäten) LED ist tot. Kurz nehme ich den steinalten Raspberry Pi 2, alles gut mit der ACT-LED.
Nach intensiven Test’s bestelle ich einen Raspberry 4 B mit 1GB.
Lasset die Spiele beginnen
Der Pi 4 ist angekommen und ich stecke Hoffnungsvoll die alte 64GB SD-Karte rein, jau, er bootet in den Desktop. Fröhlich passe ich die IP-Adresse wieder an, teste, alles bestens. Und ab damit ins 19″-Rack … nix geht mehr, wieder alles zum Arbeits-PC um letztlich festzustellen – die 64GB SD-Karte ist TOT/DEFEKT/ENDE. Dabei hatte ich am Pi 4 vorm Umbau sogar einen SHUTDOWN gemacht und gewartet bis die Drive LED aus bleibt !!
TOTAL-KATASTROPHE, denn wie der Mensch so ist länger schon kein BACKUP mehr über’s LAN gesichert. Das letzte BACKUP stammt von 09-2025 :O
So ein MIST jetzt beginnt wieder dieser ganze Dreck mit OS/APACHE/PHP/SSL/HTTPS-ZERTIFIKATE/MYSQL/WORDPRESS. Das ist ein tagelanges Gefrickel, oft ohne Sinn und Verstand.
Was ich versucht habe
Zuerst händisch wieder alles nach irgendwelchen kruden Anleitungen/Video’s zusammen-installiert.
Dann nach Tag 1 finde ich durch Zufall ein IMAGE-File auch von 09-2025. Tja, dann bin ich ja gleich fertig. Da ich Images wenn überhaupt nur mit Clone/Rescue-Zilla erstellt haben kann, Kinderspiel…von wegen.
Ich habe bestimmt EINEN TAG damit verbracht sowohl mit Clonezilla als auch mit Rescuezilla das Image zurück zu spielen, KEINE Chance.
Clonezilla ist da mal die größte Enttäuschung. Das Teil listet das Save/Restore Directory nicht mal ansatzweise komplett, findet das Image gar nicht obwohl es vor der Nase liegt.
Rescuezilla ist da viel schöner, wunderbar kann man mit der Maus navigieren. Es findet das Image ohne Probleme. Leider endet die Freude beim zurückspielen. Erst werden Partitionen generiert, dann kommt die Haupt Partition dran…ERROR. Rescuezilla meckert weil beim Ziel-Datenträger ein paar hundert Bytes zu viel/wenig da sind. Absolut lachhaft, altes Image stammt von besagter 64GB SD-Karte und soll neu auf eine 128GB SD-Karte. Wo kann es hier kapp oder eng werden ?!?!?
Jetzt kommt der größte Witz, die USB-Abbilderstellung von Linux Mint schafft es ganz easy das Image zurückzuspielen. Leider enthält der wp-content-Ordner von WordPress danach aber viel zu wenig Daten.
Jedenfalls läuft der Pi 4 erstmal mit diesem Image. Es beginnt eine Odyssee des Hacken’s per Putty, Rechte neu vergeben, Passworte vergeben, Datenbank manuell erstellen dann Import eines Datenbank-Dump’s. Dann noch WordPress die DB-Zugangsdaten beibringen.
Endlich nach gefühlt 3 Tagen sehe ich Licht am Ende des Tunnels.
Ich sehe meine Webseite, natürlich verstümmelt ohne Grafiken. Durch totalen Zufall ist der letzte erhaltene POST einer über Zertifikat Erstellung, ich folge meinem eigenen Schrieb und siehe da die Seite wieder in voller Pracht.
Dann stelle ich in WordPress unter Einstellungen/Allgemein diese beiden Seiten-Links um lösche /wordpress hinter der URL, bibbernd speichere ich. Erst klappt danach nix mehr, kriege es aber schnell wieder hin.
Dann machen natürlich wieder die Permalinks Probleme, EINFACH funktioniert, BEITRAGSNAME geht schlecht/nicht weil bestimmte Links damit nicht funktionieren. Genau das hatte ich schon mal und zum Glück hatte ich notiert wie die Lösung war.
In der /etc/apache2/apache2.conf muß unter <Directory var/www/> Allow Override auf ALL stehen. Danach mysql (mariaDB) und Apache durchstarten. Leider funktionieren danach die Permalinks mit Beitragsname genau so wenig.
Permalinks und Apache-Rewrite
Weil WordPress normalerweise bei jeder Permalink Änderung + Speichern eine versteckte .htaccess generiert, das aber dieses mal NICHT tut, erstelle ich mühsam Eine per Hand im html-Ordner
Und siehe da, mit der Permalink-Einstellung auf Beitragsname funktioniert es nun wieder.
Und ich wette das hat mit den Schreibrecht-Problem zu tun das ich nun beschreibe.
WordPress kann nicht Uploaden/Plugins Updaten usw.
Was ist das nun wieder, WordPress meckert herum will ich Bilder (Medien) uploaden.
Auch nach intensiver Recherche finde ich keine Lösung. Und natürlich mache ich ein chown rekursiv für verschiedenste Ordner.
Nächster Morgen
Es kann so einfach sein, chown ist die Lösung. Ich habe (warum auch immer) WordPress 2x, einmal direkt im html-Ordner und einmal in html/wordpress. Welches ist nun das ECHTE ?
Rekursiv, also incl. aller Unterordner, gebe ich folgenden Befehl ein :
sudo chown -R www-data:www-data /var/www/html/wordpress/wp-content/uploads
Danach starte ich den Apache einmal durch mit :
sudo systemctl restart apache2
Man kann immer noch keine Bilder hochladen :/
Dann sage ich mir nimm mal den kompletten html-Ordner incl. ALLEM :
sudo chown -R www-data:www-data /var/www/html
sudo systemctl restart apache2
ES GEHT WIEDER – WordPress kann Uploaden und es gehen auch Plugin-Updates wie gewohnt.
Nun will ich schauen WO die Bilder-Upload’s nun landen.
Leider kommt durch das chown plötzlich mein pi User nicht mehr in den html-Ordner. Ich füge den pi User der Gruppe www-data hinzu mit :
sudo usermod -a -G www-data <Benutzername>
sudo systemctl restart apache2
Nö, geht immer n.n. Da fällt mir ein, das man User Ab/Anmelden muß damit Änderungen wirksam werden. Und es funktioniert, mein Pi-User kommt wieder auf html und alle Unterordner.
Ich schaue nach wo nun der neu kreierte 2026/03-Ordner liegt und es ist /var/www/html/wp-content/uploads/2026/03
Also dürfte das WordPress in html/wordpress irrelevant sein. Bevor ich den Ordner lösche benenne ich Ihn testweise um.
sudo mv wordpress / aaaa/
WordPress läuft weiter, ich lösche den aaaa-Ordner mit sudo rm -R aaaa
Nachtrag
Und sieh mal einer an, nachdem ich eben die Permalink-Einstellungen änderte/speicherte hat WordPress in MEINE hand-getippte .htaccess die gleichen Einträge nochmals eingetragen. Ich lösche dort als mein mühsam hand-getipptes raus weil doppelt.
