goodyear

I tested the bonding suggestion, and that worked for me. After a reboot the container got the correct IP, but my network setting maybe different from yours. Next I’ll attempt an upgrade to 6.12.10 and see if that also works with regards to the container network settings surviving. EDIT: Upgraded and the network settings is indeed still sticking, I'll keep monitoring for stability:

Just wanted to add that I see this problem as well; after reboot the custom network is gone from the container settings dropdown list. Only after stopping and starting the docker service from Settings->Docker does it become available. I have for example Swag that uses a static IP on eth0, and it doesn’t get the static IP setting after a server reboot, the network type says “none” and the dropdown only has “bridge” and “host” and “none” as options, even though the container was setup with “custom”. After I stop/start the docker service the container network type is properly updated to “custom” with the correct static IP.

No crashes so far, marking as solved and will open again if I get another crash, thanks for the help!

Ok, will try it now 👍

So it happened again, and I managed to capture a screenshot of the failure from the console, and I've attached the syslog file, any ideas what may be happening? syslog-192.168.0.215.log

Thanks, will do!

Hi, I've had repeated crashes, this time at 11:42 PM, which does not coincide with any scheduled tasks (backups etc). The symptoms are no console access/HDMI output, cannot access via SSH or even ping the system IP, but the fans are spinning. I've attached the diagnostics file, which I couldn't access before reboot. The HW is according to my signature. The only thing that is "new" (since about a month back) is setting up a VM, before this I had VM support disabled and didn't experience a crash. Could be coincidental. The other abnormality is that my SWAG container doesn't work until I disable and enable the docker service after a reboot, could be relate d to giving the container a fixed IP in my subnet, not sure if this was introduced in 6.11.5 or when I enabled the VM service. Not sure how I could further troubleshoot or what could be wrong? unraidserver-diagnostics-20230427-0837.zip

I'm having the same issue, this is the content in my /var/log/gitflash file, any ideas what could be going on? I'm on the latest plugin version 2022.07.26.1609 : [2022/07/29 12:00:04 Europe/Berlin] Command 'git -C /boot reset origin/master' exited with code 128, response was: fatal: ambiguous argument 'origin/master': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' [2022/07/29 12:00:04 Europe/Berlin] Command 'git -C /boot checkout -B master origin/master' exited with code 128, response was: fatal: 'origin/master' is not a commit and a branch 'master' cannot be created from it [2022/07/29 12:00:07 Europe/Berlin] Command 'git -C /boot reset origin/master' exited with code 128, response was: fatal: ambiguous argument 'origin/master': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' [2022/07/29 12:00:07 Europe/Berlin] Command 'git -C /boot checkout -B master origin/master' exited with code 128, response was: fatal: 'origin/master' is not a commit and a branch 'master' cannot be created from it [2022/07/29 12:00:08 Europe/Berlin] Command 'git -C /boot push --set-upstream origin master' exited with code 128, response was: Host key verification failed. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. [2022/07/29 12:00:09 Europe/Berlin] Command 'git -C /boot push --force --set-upstream origin master' exited with code 128, response was: Host key verification failed. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Host key verification failed. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.

I'm using NVME for my cache drive to have it as performant as possible to support my 10GbE network, and I've set my appdata and temporary files to land there before the mover moves them to the array. My motherboard has 2 NVME slots so I've used them instead of using my SATA ports for SSD-drives, I'll rather save them for my array. I also have 980 pro drives, and I've setup them up as RAID 1. In my mind I'd always use NVME drives instead of SSD if the motherboard supports it; same price but much more performant.

I’m not sure if this is related to 6.10, but I have a dual port mellanox x2 card that is not getting assigned an IP even though I’ve set eth0 up with a static IP. I’ve set it up so that the two SFP+ ports are now eth0 and eth1 in bridged mode, with a static IP assigned to eth0, and the onboard NIC is eth 2 (unplugged). But upon reboot, the server is unreachable via the network, but it boots up fine as seen via a directly attached monitor. When I check via ifconfig , I can see that br0 has the correct static IP, but eth0, eth1 and eth2 don’t have an IP. I can’t ping the default gateway either. lsmod | grep tg3 doesn’t show anything. When I restart the network via /etc/rc.d/rc.inet1 restart the network comes up with the correct configuration. I’ve solved it by adding the network restart command as a custom script that’s run on first array start, but there is clearly an issue here. Any thoughts on what could cause this behavior? unraidserver-diagnostics-20220529-0800.zip

Will do!

I’m not sure if this is related to 6.10, but I have a dual port mellanox x2 card that is not getting assigned an IP even though I’ve set eth0 up with a static IP. I’ve set it up so that the two SFP+ ports are now eth0 and eth1 in bridged mode, with a static IP assigned to eth0, and the onboard NIC is eth 2 (unplugged). But upon reboot, the server is unreachable via the network, but it boots up fine as seen via a directly attached monitor. When I check via ifconfig , I can see that br0 has the correct static IP, but eth0, eth1 and eth2 don’t have an IP. I can’t ping the default gateway either. lsmod | grep tg3 doesn’t show anything. When I restart the network via /etc/rc.d/rc.inet1 restart the network comes up with the correct configuration. I’ve solved it by adding the network restart command as a custom script that’s run on first array start, but there is clearly an issue here. Any thoughts on what could cause this behavior? unraidserver-diagnostics-20220529-0800.zip

Latest Linuxserver Plex container release introduces permission errors in unRAID (maybe related to 6.10?). Upgraded to 6.10.1 a few days ago with no major issues, Plex was working fine last night, and this morning Plex from Linuxserver stopped working with permission errors: ****** PLEX MEDIA SERVER CRASHED, CRASH REPORT WRITTEN: /config/Library/Application Support/Plex Media Server/Crash Reports/1.26.2.5797-5bd057d2b/PLEX MEDIA SERVER/48e796f0-ca99-405e-6d6b99b6-b191e5f8.dmp Starting Plex Media Server. libc++abi: terminating with uncaught exception of type std::runtime_error: Codecs: Initialize: 'boost::filesystem::create_directory: Permission denied: "/config/Library/Application Support/Plex Media Server/Codecs/994f4ee-4302-linux-x86_64"' I have containers on auto-update, and the Plex container updated during the night, so I rolled back to version 1.26.1 (edited repository to linuxserver/plex:1.26.1) and no more errors. Question is if this is an issue on Linuxserver's Plex latest release, or if 6.10 introduced something which breaks new releases? EDIT: Reddit made me aware that the error was local, ran the following as a user script and it solved the permission issue, will check back if it reappears: #!/bin/sh for dir in "/mnt/user/appdata/plex/" do `echo $dir` `chmod -R ug+rw,ug+X,o-rwx $dir` chown -R nobody:users $dir done