ridewithjoe

I ran into an issue where the Unraid WebGUI login page worked normally, but immediately after logging in, /Mainreturned: HTTP 500 Internal Server ErrorThis happened while a disk reconstruction was actively running, so rebooting, stopping the array, or restarting emhttpdwas not an acceptable troubleshooting option. Nginx itself was working, PHP-FPM was running, the PHP socket existed, and there was plenty of free RAM-filesystem space/inodes. Nginx's error log also wasn't showing anything useful when /Main failed. The breakthrough was checking PHP's actual error log: tail -f /var/log/phplogWhen I attempted to load /Main, it showed: PHP Fatal error: Uncaught TypeError: extract(): Argument #1 ($array) must be of type array, false given in /usr/local/emhttp/plugins/dynamix/template.php:55Looking at that section of template.php showed: // Read network settings extract(parse_ini_file('state/network.ini',true));Checking the expected file: ls -l /usr/local/emhttp/state/network.inireturned: No such file or directoryHowever, searching for the runtime copy found it here: /var/local/emhttp/network.iniI initially restored that individual file: cp -a /var/local/emhttp/network.ini /usr/local/emhttp/state/network.iniThat got PHP past line 55, but /Main still returned HTTP 500. Checking /var/log/phplog again showed the next error: PHP Fatal error: Uncaught TypeError: date(): Argument #2 ($timestamp) must be of type ?int, string given in /usr/local/emhttp/plugins/dynamix/template.php:59That line depended on another state file, state/var.ini. This established that the problem wasn't limited to network.ini: multiple runtime .ini files were missing from /usr/local/emhttp/state/. Final fixInstead of restoring them individually, I copied the existing runtime state INI files from /var/local/emhttp/ into the location Dynamix was expecting: cp -a /var/local/emhttp/*.ini /usr/local/emhttp/state/I then refreshed /Main. The Unraid WebGUI immediately started working normally again. Root causeThe immediate cause was missing runtime state files under: /usr/local/emhttp/state/Dynamix's template.php expected files such as: state/network.ini state/var.inibut they weren't present. Valid copies still existed under: /var/local/emhttp/Because parse_ini_file('state/network.ini', true) returned false, PHP 8 threw a fatal TypeError when Dynamix passed that result to extract(). After restoring network.ini, PHP progressed further and failed on the missing data normally supplied by var.ini. Copying the complete set of existing .ini runtime files resolved the GUI. Important noteThis is not the first time this has happened. It is usually when intense disk activity runs for an extended period such as a rebuild or disk to disk copy operation. While a reboot generally resolves it, I did not reboot Unraid, stop the array, restart emhttpd, restart PHP-FPM, or interrupt the disk reconstruction. The repair was performed while the reconstruction continued running. The remaining question is why /usr/local/emhttp/state/ lost these runtime state files in the first place. The fix restored the GUI, but the underlying event that caused those files to disappear still needs to be determined. nasvm-diagnostics-20260915-1922.zip

I seem to remember there was the ability to configure the order of when docker containers would start. I cannot seem to remember where that is configured in 7.2.2

Running into an issue with swag on startup. seeing this error (redacted my domains and other private info) : [docker run] -d --name='SWAG' --net='br2.80' --ip='10.168.80.50' --pids-limit 2048 --privileged=true -e TZ="America/New_York" -e HOST_OS="Unraid" -e HOST_HOSTNAME="XXXXXX" -e HOST_CONTAINERNAME="SWAG" -e 'TCP_PORT_80'='80' -e 'TCP_PORT_443'='443' -e '[EMAIL'='XXXXXXXX]' -e 'URL'='XXXX.XXX' -e 'SUBDOMAINS'='XXXXXX,XXXXXX,XXXXXX' -e 'ONLY_SUBDOMAINS'='true' -e 'VALIDATION'='dns' -e 'DNSPLUGIN'='cloudflare' -e 'EXTRA_DOMAINS'='' -e 'STAGING'='false' -e 'DUCKDNSTOKEN'='' -e 'PROPAGATION'='30' -e 'MAXMINDDB_LICENSE_KEY'='XXXXXXXXXXXX' -e 'DOCKER_MODS'='linuxserver/mods:swag-maxmind' -e 'MAXMINDDB_USER_ID'='XXXXXXX' -e 'PUID'='99' -e 'PGID'='100' -l net.unraid.docker.managed=dockerman -l net.unraid.docker.webui='[IP]:[PORT:443]' -l net.unraid.docker.icon='linuxserver-ls-logo.png' -v '/mnt/user/appdata/joeproxy_2':'/config':'rw' -v '/mnt/user/remotelogs/XXXXXX/':'/var/log/':'rw' --cap-add=NET_ADMIN 'lscr.io/linuxserver/swag' Log output: Using Let's Encrypt as the cert provider SUBDOMAINS entered, processing Sub-domains processed are: XXXXXXXX E-mail address entered: [XXXXXXXX] dns validation via cloudflare plugin is selected Generating new certificate certbot: error: unrecognized arguments: --dns--propagation-seconds=30 ERROR: Cert does not exist! Please see the validation error above. Make sure you entered correct credentials into the /config/dns-conf/cloudflare.ini file. Running CERTBOT by itself works: root:/mnt/cache/appdata/cloudflare-ddns-config# docker exec -it XXXXXXX certbot certonly \ --dns-cloudflare \ --dns-cloudflare-credentials /config/dns-conf/cloudflare.ini \ --dns-cloudflare-propagation-seconds 30 \ -d XXXXXXXX \ --email [XXXXXXXX] \ --agree-tos \ --non-interactive Saving debug log to /var/log/letsencrypt/letsencrypt.log Account registered. Requesting a certificate for XXXXXXXX Waiting 30 seconds for DNS changes to propagate Successfully received certificate. Certificate is saved at: /etc/letsencrypt/live/XXXXXXXX/fullchain.pem Key is saved at: /etc/letsencrypt/live/XXXXXXXXX/privkey.pem This certificate expires on 2025-10-19. These files will be updated when the certificate renews. NEXT STEPS: - The certificate will need to be renewed before it expires. Certbot can automatically renew the certificate in the background, but you may need to take steps to enable that functionality. See https://certbot.org/renewal-setup for instructions. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Comments: This tells me that my cloudflare.ini keys are correct and the file permissions are working. I'm at a loss on what could be happening. It has been working fine for a few years. I can confirm the same error occurs when using ZeroSSL.

Running into an issue with swag on startup. seeing this error (redacted my domains and other private info) : Docker run: docker run -d --name='SWAG' --net='br2.80' --ip='10.168.80.50' --pids-limit 2048 --privileged=true -e TZ="America/New_York" -e HOST_OS="Unraid" -e HOST_HOSTNAME="XXXXXX" -e HOST_CONTAINERNAME="SWAG" -e 'TCP_PORT_80'='80' -e 'TCP_PORT_443'='443' -e 'EMAIL'='XXXXXXXX' -e 'URL'='st6.com' -e 'SUBDOMAINS'='XXXXXX,XXXXXX,XXXXXX' -e 'ONLY_SUBDOMAINS'='true' -e 'VALIDATION'='dns' -e 'DNSPLUGIN'='cloudflare' -e 'EXTRA_DOMAINS'='' -e 'STAGING'='false' -e 'DUCKDNSTOKEN'='' -e 'PROPAGATION'='30' -e 'MAXMINDDB_LICENSE_KEY'='XXXXXXXXXXXX' -e 'DOCKER_MODS'='linuxserver/mods:swag-maxmind' -e 'MAXMINDDB_USER_ID'='1190058' -e 'PUID'='99' -e 'PGID'='100' -l net.unraid.docker.managed=dockerman -l net.unraid.docker.webui='https://[IP]:[PORT:443]' -l net.unraid.docker.icon='https://raw.githubusercontent.com/linuxserver/docker-templates/master/linuxserver.io/img/linuxserver-ls-logo.png' -v '/mnt/user/appdata/joeproxy_2':'/config':'rw' -v '/mnt/user/remotelogs/XXXXXX/':'/var/log/':'rw' --cap-add=NET_ADMIN 'lscr.io/linuxserver/swag' Log output: Using Let's Encrypt as the cert provider SUBDOMAINS entered, processing Sub-domains processed are: XXXXXXXX E-mail address entered: XXXXXXXX dns validation via cloudflare plugin is selected Generating new certificate ERROR: Cert does not exist! Please see the validation error above. Make sure you entered correct credentials into the /config/dns-conf/cloudflare.ini file. Running CERTBOT by itself works: root@XXXXXX:/mnt/cache/appdata/cloudflare-ddns-config# docker exec -it XXXXXXX certbot certonly \ --dns-cloudflare \ --dns-cloudflare-credentials /config/dns-conf/cloudflare.ini \ --dns-cloudflare-propagation-seconds 30 \ -d joeflix.st6.com \ --email XXXXXXXX \ --agree-tos \ --non-interactive Saving debug log to /var/log/letsencrypt/letsencrypt.log Account registered. Requesting a certificate for XXXXXXXX Waiting 30 seconds for DNS changes to propagate Successfully received certificate. Certificate is saved at: /etc/letsencrypt/live/XXXXXXXX/fullchain.pem Key is saved at: /etc/letsencrypt/live/XXXXXXXXX/privkey.pem This certificate expires on 2025-10-19. These files will be updated when the certificate renews. NEXT STEPS: - The certificate will need to be renewed before it expires. Certbot can automatically renew the certificate in the background, but you may need to take steps to enable that functionality. See https://certbot.org/renewal-setup for instructions. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If you like Certbot, please consider supporting our work by: * Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate * Donating to EFF: https://eff.org/donate-le - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This tells me that my cloudflare.ini keys are correct and the file permissions are working. I'm at a loss on what could be happening. It has been working fine for a few years.

I ran an upgrade to day from 7.1.3 to 7.1.4 and my docker containers failed to start. It appears my VLAN interfaces on br2 are not available any longer. I rolled back and have the same issue. Not sure what went wrong. Tried removing and redefining but that hasn't worked either. nasvm-diagnostics-20250624_0745.zip

UPDATE: I restored the backup of my USB and was able to boot into UNRAID without the error and everything is working. I would be interested in know what caused the issue. I plan on replacing the USB drive just to be safe.

I just updated from 7.1.2 to 7.1.3 and rebooted. everything seems fine but seeing this banner "Your flash drive is corrupted or offline. Post your diagnostics in the forum for help." I pulled the drive and did a scandisk and it's fine and the system reboots fine but reporting this error still and docker doesn't appear to want to start. I have attached diagnostics but am assuming there is some issue with the drive that may indicate it needs replaced. nasvm-diagnostics-20250605-2021.zip

Sometime last night docker dropped and now fails to start. Cold restart of the server hasn't helped. Not seeing much in the syslog other than it failed to start. Any thoughts? nasvm-diagnostics-20250424-0856.zip

That was the better solution….while both solutions work, simply removing the IP on the interface and defining the network and gateway in the docker settings.

My expectation was that it would pick it up as well but it doesn’t… let me try removing the IP on the interface…. I don’t need an IP on it specifically. That would be a better fix.

Yes exactly except in my case br2 is not editable

This resolved the issue…. I find it odd that you cannot define the getaway in the UNRAID GUI. You can see that it is not defined but there is no capability to edit it.

I know by default that br0 is where docker is bridging... I'm using a custom config. I have 4 network interfaces.... configured into two 802.11ad bonds. bond0 and bond2. bond0 is the admin interface for unraid on a management vlan. bond2 is the interface that is a trunk interface for multiple vlans. Some dockers are on br2.80 br2 - is on vlan 60 the native vlan for the trunk. Additional vlans are: br2.10 br2.80 The bond2 interface is assigned an ip of 10.168.60.245/24 with a gateway of 10.168.60.254 I have several docker containers running on br2.80 and they are running fine. They show the proper gateway however the containers on vlan 60 should be showing the same host interface default gateway of 10.168.60.254 however they are getting a gateway of 10.168.60.1. The docker network doesn't seem to pickup the default gateway of that host interface but the sub interface is getting the gateway I have assigned. in the custom network just fine. There should be a simple way to assign a custom default gateway for a container. The output of 'docker network inspect br2': [ { "Name": "br2", "Id": "17ca4604ab87ae68e47df153062a8bbdb7e45466e5f95e1099a8d4efffb4714c", "Created": "2024-10-20T18:18:34.938423495-04:00", "Scope": "local", "Driver": "ipvlan", "EnableIPv6": false, "IPAM": { "Driver": "default", "Options": {}, "Config": [ { "Subnet": "10.168.60.0/24", "AuxiliaryAddresses": { "server": "10.168.60.245" } } ] }, "Internal": false, "Attachable": false, "Ingress": false, "ConfigFrom": { "Network": "" }, "ConfigOnly": false, "Containers": {}, "Options": { "parent": "br2" }, "Labels": {} } ] The output of 'docker network inspect br2.80': [ { "Name": "br2.80", "Id": "f22dcc51a4a813565fcc3385354c2c34e28a73f836151fe6ba25c62cc6ddb91a", "Created": "2024-10-20T18:18:35.256187663-04:00", "Scope": "local", "Driver": "ipvlan", "EnableIPv6": false, "IPAM": { "Driver": "default", "Options": {}, "Config": [ { "Subnet": "10.168.80.0/24", "Gateway": "10.168.80.254" } ] }, "Internal": false, "Attachable": false, "Ingress": false, "ConfigFrom": { "Network": "" }, "ConfigOnly": false, "Containers": { "7a7642e1c24a2409ef5aa31c8293c9c2b14c66bfae19c6247de32d1b3632bfdb": { "Name": "bhdelugevpn", "EndpointID": "a7db7f8ae3ae19cc49566e306ab334a400a4f5f15ea5fc2ef434b76a8ac4f417", "MacAddress": "", "IPv4Address": "10.168.80.1/24", "IPv6Address": "" }, "f51bea5753b086b0af16d303a6c1773715b1b8b0ef91a599749b1a510b88eb8c": { "Name": "plex", "EndpointID": "ebc4596d489b6242b007adb4f92ca75526046750300dfc26dc367b254269703f", "MacAddress": "", "IPv4Address": "10.168.80.10/24", "IPv6Address": "" } }, "Options": { "parent": "br2.80" }, "Labels": {} } ]

I have done this.... that is not the issue... the issue i that the container is not using the default gateway that is assigned to br2. The other custom networks are operating properly. I know my setup is a bit different. I am deliberately configuring a trunk interface with VLANs so that I can set certain docker containers to run on specific network subnets. nasvm-diagnostics-20241020-2105.zip