NDDan

OK, well that didn't solve my issue, there are other services that bind to ipv6 on lo that DO NOT WORK (like some pulseaudio dependencies). I was able to get this working, but @binhex I'm wondering if I could submit a feature request, or if you think this is a security issue? The containers involved for me appear to have some dependencies on loopback and binding on ipv6 in a way that I'm unable to force bind them to ipv4. To address: Specifically I created a replacement container network to enable ipv6 with a private address space (I made a new one and did that). The rules are all default all DROP, but I specifically set allows on lo for ipv6 only, replicating what you have already for ipv4: ip6tables -A INPUT -i lo -j ACCEPT ip6tables -A OUTPUT -o lo -j ACCEPT This should allow containers that reside in the vpn container network to function when they require ipv6 loopback and translation. It solved my issue, and on it's face I don't *think* I've introduced a security issue, but I will wait for the expert(s) to opine.

This is resolved. I'm not sure what changed, but I suspect it's the rdesktop container. In case this helps abyone, the problem related to the x11 session manager, it was only binding on the ivp6 address though it was set to the ipv4. Adding (to the rdesktop container) extra paramters to disable ipv6 within that container, solved the issue -- again in case it helps someone, here are the extra parms to accomplish that (DON'T to this on your privoxy container!): --sysctl net.ipv6.conf.all.disable_ipv6=1 --sysctl net.ipv6.conf.default.disable_ipv6=1

After upgrading to unRAID 7.0.0, I am having an issue with a single docker (rdesktop-Ubuntu-KDE) which is on my privoxy container network. The container natively listens on port 3389. This is the only container on my privoxy container network that I can no longer access on my LAN. I have blown the config for that container away and rebuilt it, to no avail. The ports are removed from the rdesktop container, and on the privoxy setup I have 3389 listed in VPN_INPUT_PORTS (along with others (comma separated) that ARE working properly), and have added a port for 3389 container to 3390 remapped. It doesn't work; which it did prior to 7.0.0 upgrade. The container throws NO errors and there is nothing meaningful in the rdesktop container log. From the rdesktop container's shell, I *can* reach the internet via the Privoxy VPN container that it's bound to, but I cannot connect from my LAN to port 3390 (it's not listening). To test, I've removed it from the container network and set it on the bridge network and it works perfectly. Nothing in the supervisord log looks 'off' to me, but it's attached below. Suggestions for further troubleshooting steps? supervisord_log.txt

I have not; I figured running this as a container would be outside their support terms.

There appears to be something in the new build of CrashPlan that is causing this. I reverted back to build 24.08.1 yesterday and my speeds were back to normal overnight. If you haven't done so, and you still are having the same issue, I think you could reasonably correlate that it wasn't 'fixed' miraculously overnight, but that it might be build-related. I recommend you target this repo and test: @Djoss any thoughts on this? I looked at the commit, and the changes are just the base distro v4.6.3->v4.6.4 and CrashPlan 11.4.0->11.4.1. I checked the app.log and the same endpoint is being targeted, I don't see any config differences listed either. Not sure what to make of this, but for the time being, I've reverted builds, and I'm back in business.

Yes -- 100%, I'm averaging 800kb/s, the upgrade, while not the definitive root cause, was a correlating event to the massive speed drop.

Copying and pasting the session URL into another browser to complete the login, worked perfectly, that's what I'll roll with. Thanks @DJoss!

After upgrading to the latest version of this container a few weeks ago, I'm unable to login to the gui. There is nothing special about the way I've configured this container, it's configured in bridge mode, and it's been working stably for almost two years. I'm on unraid 6.12.10, docker engine configured for macvlan network type. Suffice it to say, I can login to the CrashPlan website with the same set of credentials, and before upgrading never experienced an issue logging in through the docker app UI. I do have 2FA enabled, which I noted is now part of the login pop-up for the GUI, which was absent in previous versions of this docker app; I also have a particularly long password, and I'm wondering if there's perhaps a length limitation in the GUI that didn't previously exist? I've scoured the service.log.0 file, and there is nothing in the log I can locate that time-correlates with this login failure. Login error pop-up attached.

Bingo! Drives are back, and array started on 6.11.1. I compared the /lib version of 60-persistent-storage and the ONLY notable changes in the new kernel version include substantial modifications to the NVMe handling section, so this makes sense. I will use the new /lib version and copy it out make my edits and call my modified version back in the GO file. Thank you very much for getting me on the right track of thought here, and for reminding me that the Unraid default go file contains only a single notable entry and that everything else was 'mine'! I appreciate your expert assistance!

Thank you Jorge, I've posted that output and it got me thinking about a change I made quite a while ago to modify 60-persistent-storage.rules. I pulled (on 6.9.2) lib/udev/rules.d/60-persistent-storage.rules copied to /boot/config/rules.d, made some edits (though not to any section that should impact an NVMe--this was for an optical drive that would hang under certain media conditions and force me to hard power down the unraid server uncleanly), then modified my go file to copy it over to /etc/udev/rules.d, chmod 644, and call a udevadm control --reload-rules, and a udevadm control --attr-match=subsystem=block I'm wondering now if this kernel's build of lib/edev/rules.d version added new device methods that are needed for this kernel build, and my old storage.rules is prevailing? If I wanted to revert to this build's standard GO file, I'm honestly not sure what it looks like, I'm also copying my current GO file below in case you believe that's to blame here. I'm thinking that I need to copy this build's lib/udev/rules.d/60-persistent-storage.rules, to /boot/config/rules.d, make my edits there, so it includes any new device handling, but as a starting place, I'm fine to simply change the GO file to remove that copy and reload-rules if you think that's to blame. As I said I'm just not sure (because I was stupid and didn't comment my GO file, as to what the 'base' UnRaid GO file should contain? I've not made any changes so far, but wanted to give you that background to see what your thoughts were. 6.9.2 output from udevadm: DEVLINKS=/dev/disk/by-id/nvme-KBG40ZNS256G_NVMe_TOSHIBA_256GB_99NPCDN9PQEN DEVNAME=/dev/nvme0n1 DEVPATH=/devices/pci0000:00/0000:00:06.0/0000:01:00.0/nvme/nvme0/nvme0n1 DEVTYPE=disk ID_MODEL=KBG40ZNS256G_NVMe_TOSHIBA_256GB ID_MODEL_ENC=KBG40ZNS256G\x20NVMe\x20TOSHIBA\x20256GB\x20\x20\x20\x20\x20\x20\x20\x20\x20 ID_PART_TABLE_TYPE=dos ID_REVISION=10410104 ID_SERIAL=KBG40ZNS256G_NVMe_TOSHIBA_256GB_99NPCDN9PQEN ID_SERIAL_SHORT=99NPCDN9PQEN ID_TYPE=nvme MAJOR=259 MINOR=0 SUBSYSTEM=block USEC_INITIALIZED=14797517 6.11.1 output from udevadm: DEVNAME=/dev/nvme0n1 DEVPATH=/devices/pci0000:00/0000:00:06.0/0000:01:00.0/nvme/nvme0/nvme0n1 DEVTYPE=disk DISKSEQ=20 ID_PART_TABLE_TYPE=dos MAJOR=259 MINOR=0 SUBSYSTEM=block USEC_INITIALIZED=26250968 GO File (imported same into 6.11.1 during upgrade): #!/bin/bash # Copy and apply udev rules with additional handling for misbehaving optical drive cp /boot/config/rules.d/60-persistent-storage.rules /etc/udev/rules.d/ chmod 644 /etc/udev/rules.d/60-persistent-storage.rules udevadm control --reload-rules udevadm trigger --attr-match=subsystem=block # Start the Management Utility /usr/local/sbin/emhttp &

Been putting off moving above 6.9.2 but got tired of the nagging red triangle. Followed the process, backed-up the flash, upgraded and the array didn't start because two of the four cache drives weren't found. Reverted back to 6.9.2 and drives were found and array automatically restarted. Cache is a single pool with two SSDs and two NVE's (on mobo) (four drives total in cache pool). I've read this could require a Quirk for these two NVMe's. These were two hardware pulls from Dell laptops, and they're Toshiba 256GB NVMe's (identical models). In principal I'm willing to replace them with new Samsung NVMe's but there isn't a real 'need' in my configuration to do so other than to overcome this problem. That said, I don't want to have the same issue with two replacements, and I don't know enough to know if this is mobo related or the NVMe's themselves. For good measure I did patch the mobo FW to current, which just listed 'compatibility' fixes. Upgraded to 6.11.1 again and no dice. Currently reverted back to 6.9.2 until I can get a path forward. Attached diags for failed 6.11.1 upgrade. hgunraid01-diagnostics-20221022-1249.zip

bump...anything? Bottom line, seems like USB attached optical drives might be able to make the system unstable...whole point of using dockers for me was isolation and underlying stability. So far this is less stable than my Win10 and Win7 systems...

Thank you for the suggestion. It does sound exceedingly similar. I'm not savvy enough with unRAID to translate this to a potential solution for unRAID however. I've posted it on the unRAID:Docker Engine forum, but have not gotten any traction yet. If someone picks it up I've reference any solution here for others.

I'm new to unRAID and am having an issue with a Buffalo BU40N USB passed through to a MakeMKV docker, which in some circumstances appears to make the entire system unstable. (I've tested the hardware on another platform, it's fine). Most recently, when loading a DVD, the drive seeks infinitely without mounting the disk (within MakeMKV at least). I've also noted this behavior with a BluRay that it had difficulty reading. Under these error read conditions the docker becomes unstable and then in turn the unRAID system becomes unstable. The result is that I have to bring the server hard down. Involved docker is Djoss' MakeMKV FWIW, last item in the docker's logfile is "[s6-finish] syncing disks"...it hangs there when it becomes unresponsive. Can't kill the docker through the GUI, bringing it down via CLI with docker stop/kill don't work. Docker container is finally stopped via SIGKILL. That said array won't shutdown via poweroff script at that point despite no locks on mounted volumes. Notably when this condition occurs at least one CPU core is pegged with nothing else running. Seems that this USB device creates an unstable system state. DJoss graciously pointed me over to a support thread on the MakeMKV forum that references a very similar situation with Ubuntu: https://forum.makemkv.com/forum/viewtopic.php?f=3&t=25357&p=109149&hilit=hang#p109149 Unfortunately I'm not savvy enough to translate this to unRAID or indeed to even know if there's reason to believe there an overlap. Any insights?

Starting off--new to unRAID and to Dockers in general. Not having an issue with any other docker -- strange situation with the MakeMKV one. Firstly, I have a Buffalo USB drive, I've exposed both linux devices to the container. It can read *some* disks, but when it has a problem and just reads forever--either loading the disk or during ripping--the container hangs and can't be shutdown...it's worse than that as even killing the associated processes still don't allow the array to be shutdown successfully and I have to go unclean hard down. I've pulled the drive over to the same release of MakeMKV on Windows10--it does not become unresponsive under those conditions. So in other words I was trying to eliminate a specific disk or drive issue. In the container log it always hangs on 'syncing disks'--even if I haven't gotten past the actual identification of the disk, when trying to stop the container it hangs there. I'm not running the container in priveleged mode. I am exposing both drive devices through extra parameters. This is happening with the latest release and with the last most recent container release. Bottom line is that everything's golden if the disk reads perfectly, but when it doesn't, then I have to hard down the server because I can't get the container to shut down. My instinct tells me there is something here with permissions and possibly the fact this is USB hardware. What's not clear is why the container is stuck on synching disks and won't allow the array to shutdown or the container to stop gracefully. Thoughts?