jxjelly

Unfortunately, my situation has gone in the reverse direction. I previously got the error but was able to connect remotely, now I still get the error but am unable to connect remotely.

Then I apologize

Then why are you replying? This post was made specifically in the Unraid Connect section and was asking for help with unraid connect

Does windows care if the UUID suddenly changes? I have a old baremetal installation that i've converted into a vm from your tutorials but have been worried about changing the UUID on it for non-gpu vms

Booted up windows to get the log and ran into a memory related blue screen. Running memtest64 getting errors on 4, 6 & 7. So this is probably the cause of my issues.

It is disabled on my router and in my network settings. This weekend I had my longest period of uptime in a while from Friday till 4AM Monday. I'll have to pull the logs again when I get home.

I'm still having issues this time no nvidia crash in the logs. Nginx keeps giving me issues. syslog

You know what, I think I also sent my syslogs to a share on the cache drive which might be why it wouldn't go offline from the physical power button

Tried turning the computer off with the power button which took down docker but didn't complete shutting down. I was able to ssh in and /etc/rc.d/rc.php-fpm restart allowed me to reach the gui again. I saw the server was prevented from shutting down because it ran into trouble shutting down the array. Shutting down cache drive around 18:41 Couldn't get the diagnostics because it was freezing at nvidia-smi Gui went unresponsive a few times while navigating the server. the php restart got it back every time. Ultimately the restart button in the gui got it to restart. Looking at the syslogs Oct 20 07:47:36 Monolith webGUI: Successful login user root from 209.107.189.2 [...] Oct 20 07:48:47 Monolith php-fpm[5983]: [WARNING] [pool www] server reached max_children setting (50), consider raising it At 07:47 was the last time I was able to log in. The other line I included above I wonder if it is the problem. Not sure why I'm hitting so many max children. Oct 20 20:18:48 Monolith kernel: _swap_info_get: Bad swap file entry 3ffffffffffbf Oct 20 20:18:48 Monolith kernel: BUG: Bad page map in process php-fpm pte:00008000 pmd:1a6f38067 Oct 20 20:18:48 Monolith kernel: addr:0000154493f33000 vm_flags:00000075 anon_vma:0000000000000000 mapping:ffff888107c6f3e8 index:ee Oct 20 20:18:48 Monolith kernel: file:libc-2.36.so fault:shmem_fault mmap:shmem_mmap read_folio:0x0 Oct 20 20:18:48 Monolith kernel: CPU: 0 PID: 29542 Comm: php-fpm Tainted: P D W O 5.19.14-Unraid #1 Oct 20 20:18:48 Monolith kernel: Hardware name: Gigabyte Technology Co., Ltd. Z390 AORUS PRO WIFI/Z390 AORUS PRO WIFI-CF, BIOS F12 11/05/2021 This bit also looked suspicious And then apologies for the end of the syslogs I had to reboot a few times to get access and download them and diagnostics (different issue for another time) monolith-diagnostics-20221020-2114.zip syslog

I've been having the same issues; enabled syslog mirror to flash and it just happened again. Will post my logs when I get home tonight. Also if I give the GUI long enough to load I eventually get an nginx "500 Internal Server Error"

So, could you tell me if the following is a bad idea or not? A docker I want to run on dockerhub copies all of its working files to /sd in the Dockerfile. And because of what you explained above by mapping /sd:%appdata%/sd the container doesn't see its files anymore because the files are covered up by the bind-mount. If I add a Post Argument of: mv -f /sd/* /appdata && ln -s /appdata /sd and change my mapping to /appdata:%appdata%/sd would it read across the link fine?

I don't think this is the correct way to do this. Not sure what problems you were having with the standard config. This worked for me, just make sure you're on the same network as SWAG ## Version 2021/05/18 # make sure that your dns has a cname set for <container_name> and that your <container_name> container is not using a base url server { listen 443 ssl; listen [::]:443 ssl; server_name audiobookshelf.*; include /config/nginx/ssl.conf; client_max_body_size 0; # enable for ldap auth, fill in ldap details in ldap.conf #include /config/nginx/ldap.conf; # enable for Authelia #include /config/nginx/authelia-server.conf; location / { # enable the next two lines for http auth #auth_basic "Restricted"; #auth_basic_user_file /config/nginx/.htpasswd; # enable the next two lines for ldap auth #auth_request /auth; #error_page 401 =200 /ldaplogin; # enable for Authelia #include /config/nginx/authelia-location.conf; include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; set $upstream_app audiobookshelf; set $upstream_port 80; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } }

None of them are running, I had accidentally run two of them the other day to test something and the killed each other, but the OOM error occurred like a day later. Also the first time this happened none of them were running either, but a parity check was happening.

Could it be related to these windows being unresolved from this other issue of mine that started with 6.11?

Not sure what caused it or what was killed. This is the second time this has happened since 6.11, the first time I rebooted before getting diagnostic. monolith-diagnostics-20221002-1016.zip