pappaq

Members
  • Posts

    134
  • Joined

  • Last visited

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

pappaq's Achievements

Apprentice

Apprentice (3/14)

4

Reputation

  1. And I am having the "File not found." error again after rebooting my server. Attached is the last diagnostics from yesterday. I don't want to set up my server again from scratch this time. Does anybody got a clue? dringenet-ms-diagnostics-20220714-2006.zip
  2. I've never had this error. BUT today the electricity was gone for five hours and my server was cut from electricity abruptly. Could you guys please take a look at the diagnostics? Thanks dringenet-ms-diagnostics-20220714-2006.zip
  3. I've deleted the docker img and VM image and set up everything from scratch. The server ist running now witout a problem for nearly 4 days straight. Looks solved. If it occures again, I will report here.
  4. I suspect more and more that it has something to do with the shares. Every time I start working on the shares in the main tab, the error comes up. I will try to reproduce the behavior...
  5. I have not had any problems with this so far. It was pretty full about two years ago and I enlarged it. No problems with that since. I am going to reboot again and going to fix the shares.
  6. fortunately, the error occured again yesterday, some time after the reboot. There does not seem to be smth. wrong.
  7. I've rebooted the server before I read your comment...I've taken diagnostics and df -h shows no particular partition filling up over the course of the last 10 minutes. The diagnostics are after the fresh reboot. I don't know if they help. And it seems like the only full drives are the data drives inside the pool, so no problem there? I will have a look at it for the next hours and watch the partitions closely. Thanks. dringenet-ms-diagnostics-20220226-1434.zip
  8. The scripts are super basic move scripts which are triggered by cron every few minutes. Worked for month.
  9. How should I have known that the command will vanish when the error occures? It normally returns to normal operation after the reboot. Currently I've got no time to test. Furthermore my heating is automated via home assistant running on the server, making downtimes and disabling Dockers and VMs to my last resort. I will try restarting and posting diagnostics then. Maybe you can review it then and tell if there is anything that indicates this kind of behavior.
  10. Ok, everytime I try to load the GUI in any browser the following error occures in the syslog: Feb 25 10:39:04 dringenet-MS nginx: 2022/02/25 10:39:04 [error] 23909#23909: *118637 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 192.168.1.195, server: , request: "GET /Main HTTP/2.0", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "cbc341bc4a11f139b471cdbe9e9ff76f4eeef8eb.unraid.net" Feb 25 10:39:05 dringenet-MS nginx: 2022/02/25 10:39:05 [error] 23909#23909: *118637 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 192.168.1.195, server: , request: "GET /Main HTTP/2.0", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "cbc341bc4a11f139b471cdbe9e9ff76f4eeef8eb.unraid.net" Feb 25 10:39:06 dringenet-MS nginx: 2022/02/25 10:39:06 [error] 23909#23909: *118637 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 192.168.1.195, server: , request: "GET /Main HTTP/2.0", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "cbc341bc4a11f139b471cdbe9e9ff76f4eeef8eb.unraid.net" Feb 25 10:39:07 dringenet-MS nginx: 2022/02/25 10:39:07 [error] 23909#23909: *118637 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 192.168.1.195, server: , request: "GET /Main HTTP/2.0", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "cbc341bc4a11f139b471cdbe9e9ff76f4eeef8eb.unraid.net" Feb 25 10:39:07 dringenet-MS nginx: 2022/02/25 10:39:07 [error] 23909#23909: *118637 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 192.168.1.195, server: , request: "GET /Main HTTP/2.0", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "cbc341bc4a11f139b471cdbe9e9ff76f4eeef8eb.unraid.net" Feb 25 10:39:08 dringenet-MS nginx: 2022/02/25 10:39:08 [error] 23909#23909: *118637 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 192.168.1.195, server: , request: "GET /Main HTTP/2.0", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "cbc341bc4a11f139b471cdbe9e9ff76f4eeef8eb.unraid.net" Does anybody got a clue?
  11. And we are back to square one. The bug is back. And strangely enough the diagnostics command is gone as soon as the bug occures. I can provide the syslog.txt only...If nobody got a clue I will try to investigate next weekend. After disabling netdata docker the "FastCGI sent in stderr: "Primary script unknown"" is gone and does not spam the logs. But now I see that nothing really indicates smth. strange in the logs that indicates the bug. Soooo I am going to try safemode etc. when I find the time and will report back here. This fucking sucks and will cost so much time...
  12. Ok, I've reinstalled the flash drive and copied my config to it. Server back up and running. diagnostics is a command now... I think I have never had a clean installation since I've started using unraid. And I changed the hardware and setups multiple times. If the error occures again I will post the diagnostics. Thank you so much trurl for your support!
  13. I thought I had installed a plugin which was configured to make frequent backups...didn't check it for a long time though. Checked the flash drive and found no errors. Made a backup. Trying it again now. Could you guide me to a tutorial to reinstall the flash drive?
  14. Is there a way to bring the "diagnostics" command back to life?
  15. I have not tried that. Everything works except the GUI. Restarting nginx via etc/rc.d/rc.nginx restart didn't help either... I've got a flash backup from march last year...that would be my last resort. I opened this thread before that, so I guess it does not guarantee to solve the issue, because the current behavior occured before march last year. Is there another way maybe? The server run 120 days after the last reboot without any issues...