Chlorgas

Hello, I want to solve this specific (php-) error from passman: { "reqId": "ZU1i5UVHRM902ej4RGVq", "level": 3, "time": "2025-11-17T21:45:02+00:00", "remoteAddr": "", "user": "--", "app": "PHP", "method": "", "url": "--", "message": "OCA\\Passman\\Service\\CredentialRevisionService::getRevision(): Implicitly marking parameter $user_id as nullable is deprecated, the explicit nullable type must be used instead at /config/www/nextcloud/apps/passman/lib/Service/CredentialRevisionService.php#87", "userAgent": "--", "version": "32.0.1.2", "data": { "app": "PHP" }, "id": "691b9811cb89b" }Can anybody lead me to a proper fix for that? Many thanks in advance! edit, 19.11.2025: I've found this bug report: https://github.com/bcit-ci/CodeIgniter/issues/6302 But all the file locations are not available on my undraid-instance nor in the nextcloud docker.

I also got this message and went according to this tutorial: https://www.c-rieger.de/nextcloud-und-php-troubleshooting/

7.1.2 --> 7.1.3 and encountered no problems.

7.1.3 --> 7.1.4 and no problems encountered.

So, I just follow spaceinvaderone's instruction in preparation, then put all disks into the new machine mounting it via unassigned devices, copy everything onto the new cache and pool and at last start all the dockers again, right?

What would be the process if I have complete new drives? Is there a simple solution for moving the data accordingly?

Thanks for that!! Worked for me as well!

Same here. Log says: [info] Initialisation started... [info] influxdb fixed. [info] loki fixed. [info] telegraf fixed. [info] promtail fixed. [info] grafana fixed. [info] Initialisation complete [info] Runing apps... [info] Run influxdb as service on port 8086 Executable /usr/bin/influxd does not exist! [info] Run loki as daemon on port 3100 [info] Run telegraf as service [info] Run promtail as daemon on port 9086 [info] Run grafana as service on port 3006 * Starting Grafana Server ...fail! [info] All done [error] influxdb crashed! [error] loki crashed! [info] Skip hddtemp due to USE_HDDTEMP set to no [error] telegraf crashed! [info] promtail PID: 77 [error] grafana crashed!

Vielen Dank @base64! Habe alles gesichert und wegkopiert, den Mover laufen lassen und konnte danach die Datenbank ohne Fehler wiederherstellen!

Also /mnt/user/ und dann habe ich alles am aktuellsten Stand beieinander. Dann teste ich das mal mit einer neuen mariadb-Installation.

Da ist alles vorhanden. Ich bin mir nur nicht sicher was ich mit /mnt/user und /mnt/user0 mache. Was muss ich hier sichern, um einen Fehler oder file corruption zu vermeiden?

Grüß euch! Ich glaube, meine Shares bzw. deren Pfade ordentlich totkonfiguriert habe und benötige Hilfe von euch Spezialisten hier. Das Problem stellt sich wie folgt dar: Nachdem ich die Pfade in den Docker-Settings verändert habe, starten meine Dienste nicht mehr. Ich habe anschließend die Pfade zurückgesetzt (2025_0327 unraid 01.png), aber meine Datenbank (mariadb) startete nicht mehr bzw. mit fortlaufenden Fehlern im Log. Ein Löschen des Containers und Neuinstallation via User-Template funktionierte auch nicht. Ich habe anschließend ein Restore via Appdata BackUp durchgeführt und konnte die Dienste wieder starten. Danach wollte ich die Fehler aus "Fix Common Problems" bereinigen: Share xxx is set to cache only, but files / folders exist on the array Share xxx is to to not use the cache, but files / folders exist on the cache drive und zwar wie hier beschrieben: Das führte dazu, dass meine Docker nicht mehr in der Übersicht sichtbar sind. Als ich diese via User-Template neu installieren wollte, trat ein Installationsfehler auf (2025_0327 unraid 03.png). Ich habe das betreffende Verzeichnis via SSH geprüft, aber das ist leer (2025_0327 unraid 04.png). Nun tritt Panik ein, da es sich hier um meine nextcloud-Datenbank handelt und die sollte natürlich wieder laufen. Der Endzustand sollte so aussehen, dass meine Docker-Images im Cache (Share: system) gespeichert werden und die User-Daten auf dem Array (Share: appdata) liegen. Die nextcloud-Dateien sollten getrennt davon im Array (Share: nextcloud) gespeichert werden und paperless-Daten sollen auch am Array (Share: paperless-ngx_data) gespeichert sein (Shares sieht man in 2025_0327 unraid 02.png). Screenshots und diagnostic sind angehängt, weitere Details reich ich gerne nach, wenn notwendig. Kann mich bitte jemand in DAU-Sprech anweisen, wie ich das wieder hinbekomme? Vielen Dank im Voraus! Docker-Übersicht: Shares: Fehler maraidb: Verzeichnis des Fehlers: Diagnostic:

Thanks for the fast support, @ich777. Everything seems up and running again!

Hello! I'm running unraid 6.12.13 and updated PP today. After restart i see a blank page saying: "Version 17 of JVM is not suitable for this product. Version: 21 or greater is required." Does someone has a hint for me solving this issue? Thanks in advance!

How did you solve it?

Update 6.9.2 -> 6.10 got error 404 on acces via FQDN reloaded the page via IP-Adress and login was possible reloaded via FQDN and no error 404 was there login possible everything works fine for me.^^

Hi, Revan335! Ich binde mittels NFS-Freigabe ein freenas-Datengrab in unraid ein. Das funktioniert zuverlässiger als SMB und ich habe mir mit der genauen Rechtverwaltung leichter getan. Zugriff findet von mir ausschließlich über unraid statt und nicht mehr direkt über freenas.

@ich777 Wow!! Das hat funktioniert! IP-Adressen kann ich wieder auf br0 statisch einstellen. Alle Daten sind wohlbehalten da, Datenbanken laufen und alles sieht so aus wie zuvor! Vielen, vielen Dank, @ich777 und @mgutt für die geduldige Unterstützung, Analyse und Beratung! Danke!

Alles klar, dann starte ich da mal. Ich danke dir für die vielen Infos und Anleitungen und melde mich hoffentlich mit Erfolg später wieder hier.

Ok, das kann ich versuchen. Ich wiederhole nochmal, um sicher zu gehen, dass ich dich verstanden habe: Die Docker-Images werden gelöscht und wiederhergestellt. Meine Daten (nextcloud) bleiben erhalten. Ich lege den Dockeriamge-Pfad auf ein anderes Verzeichnis und starte dort die Wiederherstellung aller Docker in der Reihenfolge, wie sie aktuell ersichtlich sind. Darüber hinaus vergebe ich die selben Namen und Einstellungen. Korrekt? Ja, deine Einträge bezüglich der Netzwerkeinstellungen stimmen mit meinen überein (IP-Adressen ausgenommen).

Also, ja. Ich habe hier eine Nextcloud-Instanz laufen (gehabt). Darin enthalten sind Kalender, Handy-Sicherung, Kontakte usw... Davon habe ich Backups, die mittels "CA Backup / Restore Appdata" alle 7 Tage erstellt und auf ein anderes Share gesichert werden. Vorm neu erstellen, habe ich Riesenbammel, da ich mir nicht sicher bin, ob ich es ordentlich hinbekomme. Der Verlust aller anderen Container neben nextcloud ist verschmerzbar und stellt kein Problem dar. Was meinst du mit "Pfad wechseln"? Die Docker nicht in /appdata/ installieren? Ja, genau das Menü suche ich!

Ich habe nur eine NIC eingebaut: eth0 (onboard NIC) Ok, bond ist aus. aber ich kann die Container nicht auf br0 stellen.

@ich777 Ist im Anhang.... Danke für's Angucken!!

@mgutt Das wäre umgestellt, bringt aber keine Besserung. und die Ausgabe der aktuellen Routen root@Tower:~# ip route show table all default via 192.168.0.1 dev br0 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 192.168.0.0/24 dev br0 proto kernel scope link src 192.168.0.100 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1 local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 broadcast 172.17.0.0 dev docker0 table local proto kernel scope link src 172.17.0.1 linkdown local 172.17.0.1 dev docker0 table local proto kernel scope host src 172.17.0.1 broadcast 172.17.255.255 dev docker0 table local proto kernel scope link src 172.17.0.1 linkdown broadcast 192.168.0.0 dev br0 table local proto kernel scope link src 192.168.0.100 local 192.168.0.100 dev br0 table local proto kernel scope host src 192.168.0.100 broadcast 192.168.0.255 dev br0 table local proto kernel scope link src 192.168.0.100 broadcast 192.168.122.0 dev virbr0 table local proto kernel scope link src 192.168.122.1 linkdown local 192.168.122.1 dev virbr0 table local proto kernel scope host src 192.168.122.1 broadcast 192.168.122.255 dev virbr0 table local proto kernel scope link src 192.168.122.1 linkdown local ::1 dev lo proto kernel metric 0 pref medium ::1 dev lo proto kernel metric 256 pref medium local fe80::68eb:19ff:fecd:9d36 dev di-8ae606ca1d97 proto kernel metric 0 pref medium fe80::/64 dev di-8ae606ca1d97 proto kernel metric 256 pref medium multicast ff00::/8 dev di-8ae606ca1d97 proto kernel metric 256 pref medium @ich777 Eine network-rules.cfg habe ich nicht im Verzeichnis /boot/config Die network.cfg habe ich gelöscht und neu gestartet. eth0 hatte keine neue IP, sondern ist mir der alten wieder ansprechbar gewesen. Ich konnte mich danach einloggen, habe die eth0 auf static umgestellt und beim Speichern der Settings ist die Maschine eingefroren. Der Server scheint in der ARP-Tabelle meiner Firewall nicht auf und reagiert auch nicht auf einen Ping. Nach einem weiteren Neustart sieht ifconfig so aus: ~# ifconfig bond0: flags=5443<UP,BROADCAST,RUNNING,PROMISC,MASTER,MULTICAST> mtu 1500 ether 60:45:cb:a0:dd:85 txqueuelen 1000 (Ethernet) RX packets 2496 bytes 835206 (815.6 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 3250 bytes 2101076 (2.0 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.0.100 netmask 255.255.255.0 broadcast 0.0.0.0 ether 60:45:cb:a0:dd:85 txqueuelen 1000 (Ethernet) RX packets 2327 bytes 790082 (771.5 KiB) RX errors 0 dropped 61 overruns 0 frame 0 TX packets 2181 bytes 2043046 (1.9 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 di-8ae606ca1d97: flags=195<UP,BROADCAST,RUNNING,NOARP> mtu 1500 inet6 fe80::b4ad:f8ff:fe36:54b prefixlen 64 scopeid 0x20<link> ether b6:ad:f8:36:05:4b txqueuelen 0 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 3 bytes 210 (210.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255 ether 02:42:42:5b:70:f7 txqueuelen 0 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth0: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST> mtu 1500 ether 60:45:cb:a0:dd:85 txqueuelen 1000 (Ethernet) RX packets 2496 bytes 835206 (815.6 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 3250 bytes 2101076 (2.0 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device memory 0xf6500000-f651ffff lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1000 (Local Loopback) RX packets 741 bytes 217807 (212.7 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 741 bytes 217807 (212.7 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255 ether 52:54:00:f2:e9:5f txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 Trotzdem kann ich in den einzelnen Docker keine br0 mit statischer IP zuweisen. Der Menüeintrag ist nach wie vor nicht vorhanden.

Folgende Historie gilt für meinen Server: Eingerichtet wurde alles mit der onboard NIC. Nach etwa zwei Jahren habe ich dann 2 weitere PCI-Karten (mit je zwei ports) eingebaut. Aufgrund der Tatsache, dass ich es nicht geschafft habe, diese in die DMZ einzubinden, habe ich sie wieder ausgebaut. Am Donnerstag habe ich dieses Unterfangen noch einmal versucht und bin wieder gescheitert. Diesmal ist aber noch irgendetwas schief gegangen, da ich die bestehende Konfiguration auch nicht wiederherstellen konnte. Deine Vorschläge werde ich auch Sonntag Abend umsetzen.