-
-
[Support] swiss01 - eas3-mqtt-gateway
This is the support thread for the docker templates I have added to community apps. You can find my templates on GitHub at - swiss01 eas3-mqtt-gateway Application: eas3-mqtt Docker Hub: https://hub.docker.com/repository/docker/swiss01/eas3-mqtt/general GitHub: https://github.com/sr258/eas3-mqtt GitHub: https://github.com/swiss01/eas3-mqtt-Dockerfile Documentation: https://github.com/sr258/eas3-mqtt/blob/main/README.md
-
Die Suche nach einer neuen Unraid Hardware (zum mitdiskutieren)
Danke fürs richtig stellen. In früheren Diskussionen habe ich es in dem fall falsch verstanden und meinte, das die Parity ein Raid 1 machen. Mit einem Raid 6 macht das ganze aber mehr Sinn.
-
Die Suche nach einer neuen Unraid Hardware (zum mitdiskutieren)
Also ich glaube Unraid unterstützt zwei Array's gar nicht. Zwei Parity platten bringt nicht viel, denn wenn zwei Datenplatten aussteigen, sind die daten auch weg. Ausser du hast glück und es steigt eine Parity und eine Datenplatte aus. Ein Backup ist zudem recht unsinnig, dies auf dem selben Rechner zu machen. Bei Diebstahl, Feuer- Wasser- Stromschaden sind auch alle daten weg. Falls es aber nur Sicherung für "dumm gelaufen" sein soll, also "ups ich habe die daten aus versehen gelöscht" und will es widerherstellen, kannst du auch gut alles auf einem Array machen. Sprich eine Parity und 7 Datenplatten. Ich würde das aber bedenken, dass z.B. 3x 10TB Platten stromsparender sind als 8x 3TB Platten.
-
Die Suche nach einer neuen Unraid Hardware (zum mitdiskutieren)
Ja habe das Board genommen. Mein Setup ist ASUS TUF GAMING B760M-PLUS Intel i5 14500 Samsung 970 EVO Plus 2x Corsair Vengeance 2 x 16GB, 7200 MHz, DDR5-RAM, DIMM (nicht übertakt) Seagate Exos X20 20TB 3x Das ganze braucht im idle so zwischen 22-27w wobei an dem USV noch der Router und ein Glasfaser zu RJ45 konverter hangen. Die brauchen glaub so 7w. Wenn ich das recht im kopf habe. Wie genau die messung ist kann ich nicht sagen. Die daten kommen vom USV selbst Kann zum Board eigendlich nicht viel sagen. Es lauft und ich habe keine Probleme damit.
-
[Support] swiss01 - SplitPro
I'm not familiar with Tailscale. I just see that it's supposed to be based on Wireguard. So my first question is, why not use Wireguard directly, since it's already integrated into Unraid? But since Tailscale is just a VPN, SplitPro, if configured correctly, should be accessible and working on the home network. If not, I assume you've entered the NEXTAUTH_URL variable incorrectly. Since you're not accessing it via a domain, you should actually specify the IP address and probably also the port of the container. Give it a try.
-
Server not reachable
Thank you very much, I have 7.1.0-beta.3 installed and have had no problems for 29 days. In a week the 7.1.0 will be installed 🙂
-
[Support] swiss01 - SplitPro
I found this in the instructions. POSTGRES_USER="postgres" POSTGRES_PASSWORD="strong-password" POSTGRES_DB="splitpro" DATABASE_URL="postgresql://postgres:strong-password@splitpro-db-prod:5432/splitpro" I think the URL should look like this. DATABASE_URL="postgresql://splitpro-db-prod:5432" I tested it and it doesn't work for me. It could be a bug in the repository. Since I only created the Unraid template, I can't help you any further. I suggest changing the password or reporting it on GitHub. https://github.com/oss-apps/split-pro
-
Server not reachable
Thanks for your reply. I just implemented the excessive-flash-drive-activity-slows-the-system-down thing. Today, two days after a reboot, I had the problem again. I was just able to restart the server normally. Shutting down Docker or the VM didn't help this time. I couldn't download the diagnostics. The syslogs were flooded, even when Docker and the VM Manager were shut down. These few lines were written repeatedly. The syslog is now larger than 100MB and only contains data from March 14-29, 2025. Mar 29 18:56:31 Tower nginx: 2025/03/29 18:56:31 [alert] 1980817#1980817: *827646 header already sent while keepalive, client: 192.168.1.10, server: 192.168.1.21:443 Mar 29 18:56:31 Tower kernel: nginx[1980817]: segfault at 0 ip 0000000000000000 sp 00007ffe4356a588 error 14 in nginx[400000+24000] likely on CPU 2 (core 4, socket 0) Mar 29 18:56:31 Tower kernel: Code: Unable to access opcode bytes at 0xffffffffffffffd6. Mar 29 18:56:31 Tower nginx: 2025/03/29 18:56:31 [alert] 10793#10793: worker process 1980817 exited on signal 11 Mar 29 18:56:31 Tower nginx: 2025/03/29 18:56:31 [crit] 1980818#1980818: ngx_slab_alloc() failed: no memory Mar 29 18:56:31 Tower nginx: 2025/03/29 18:56:31 [error] 1980818#1980818: shpool alloc failed Mar 29 18:56:31 Tower nginx: 2025/03/29 18:56:31 [error] 1980818#1980818: nchan: Out of shared memory while allocating channel /dockerload. Increase nchan_max_reserved_memory. Mar 29 18:56:31 Tower nginx: 2025/03/29 18:56:31 [alert] 1980818#1980818: *827649 header already sent while keepalive, client: 192.168.1.10, server: 192.168.1.21:443 Mar 29 18:56:31 Tower kernel: nginx[1980818]: segfault at 0 ip 0000000000000000 sp 00007ffe4356a588 error 14 in nginx[400000+24000] likely on CPU 2 (core 4, socket 0) Mar 29 18:56:31 Tower kernel: Code: Unable to access opcode bytes at 0xffffffffffffffd6. Mar 29 18:56:31 Tower nginx: 2025/03/29 18:56:31 [alert] 10793#10793: worker process 1980818 exited on signal 11 Mar 29 18:56:31 Tower nginx: 2025/03/29 18:56:31 [crit] 1980819#1980819: ngx_slab_alloc() failed: no memory Mar 29 18:56:31 Tower nginx: 2025/03/29 18:56:31 [error] 1980819#1980819: shpool alloc failed Mar 29 18:56:31 Tower nginx: 2025/03/29 18:56:31 [error] 1980819#1980819: nchan: Out of shared memory while allocating channel m/ I have 32 GB of RAM, and it should work. Memtest ran for a good 18 hours without any errors. Latest BIOS installed, and the CPU is oversized. My System Title Information System Overview Unraid system: Unraid server Pro, version 7.0.1 Model: Custom Motherboard: ASUSTeK COMPUTER INC. TUF GAMING B760M-PLUS, Version: Rev 1.xx, s/n: 230926644903196 Processor: Intel® Core™ i5-14500 @ 2574 MHz HVM: Enabled IOMMU: Enabled Cache: L1 Cache = 288 KiB (max. capacity 288 KiB) L1 Cache = 192 KiB (max. capacity 192 KiB) L2 Cache = 7680 KiB (max. capacity 7680 KiB) L3 Cache = 24 MiB (max. capacity 24 MiB) L1 Cache = 256 KiB (max. capacity 256 KiB) L1 Cache = 512 KiB (max. capacity 512 KiB) L2 Cache = 4 MiB (max. capacity 4 MiB) L3 Cache = 24 MiB (max. capacity 24 MiB) Memory: 32 GiB DDR5 (max. installable capacity 256 GiB) Controller0-DIMM1: Corsair CMK32GX5M2X7200C34, 16 GiB DDR5 @ 4800 MT/s Controller1-DIMM1: Corsair CMK32GX5M2X7200C34, 16 GiB DDR5 @ 4800 MT/s Network: eth0: 1000 Mbps, full duplex, mtu 1500 Kernel: Linux 6.6.78-Unraid x86_64 OpenSSL: 3.4.1 P + Q algorithm: 25872 MB/s + 46949 MB/s
-
Server not reachable
Good evening. It's that time again. After a good 15 days and 7 hours, I can still access the web GUI, but I have to wait about 30-60 seconds each time for the page to load. It's especially slow when I switch tabs in the menu, but it's still OK. I then turned off the VM Manager. Since then, it's been running smoothly again. Only now I can't turn on the VM Manager anymore. I then turned off the Dockers, and I can start them again. Okay, now things are getting weird. I wanted to restart the server and went back to the VM tab. They're running again. The VM Manager started again after I turned off the Dockers. Well, I'll restart the server, then hopefully I'll have another 15 days of peace. Below is the diagnostic data. tower-diagnostics-20250326-2140.zip
-
Server not reachable
thank you. then we'll wait until the server crashes next time I'll get back in a few weeks
-
Server not reachable
Hello everyone I've had the problem for a while that my server becomes extremely sluggish after a certain amount of time. It can take a week or 2-3 weeks for it to occur. Last Thursday, February 27, 2025, it happened again. I could no longer access Docker or a VM. The WebUI could no longer be accessed either. Nothing worked via SSH either. Everything I tried seemed as if it was still there but the server was completely overloaded, so that at some point it would time out. The HDDs were all off according to my girlfriend (i wasn't at home) and the server couldn't be turned off using the power button. So the only option was to kill the server. I've had this problem about 4 times now, although I was still able to access the WebUI somehow and restart the server properly. I had this problem once before with 6.12.14. I thought the problem might be solved with 7.0.0 but unfortunately not. Unfortunately I couldn't find anything in the logs either, as some of them get lost when you restart? Anyway, I've attached the logs. Does anyone know the problem or can help me? tower-diagnostics-20250302-2217.zip
-
[Support] swiss01 - SplitPro
That's not the problem. I have a separate email address that only covers things like that, but with that I can send emails myself via Splitpro. I've just tested it.
-
[Support] swiss01 - SplitPro
I suspect that Google is blocking itself for security reasons. Go to your Google account and look for "app password", create one for SplitPro and then use the password to send an email via Docker.
-
[Support] swiss01 - SplitPro
I also use gmail and it works for me with EMAIL_SERVER_HOST = smtp.gmail.com EMAIL_SERVER_PORT = 465
-
[Support] swiss01 - SplitPro
ah, sorry. I thought you were already logged in. That's right, with splitpro you say "add expense" to log in. I think I had that error once too. did you enter the right address for "NEXTAUTH_URL"? So either the IP of the Docker or, if it should be accessible from outside, your domain