ken-ji

@noski @NKnusperer Did you add the network to the Docker settings? Make sure to have the array stopped and to toggle the Advanced view in the upper right corner.

A VLAN is a different subnet just sharing the same physical connections as the main subnet. So when a new VLAN is configured, you'll need to configure the router (in your case pfSense) to know about the VLAN and support it as well. So for devices on different VLANs / subnets to reach each other, it absolutely needs to go through a router. If the devices are on the same VLAN/subnet they will ignore the router and communicate directly.

To limit host to VM and VM to host communications, you want them to go through a firewall - this can be done on the Unraid level via iptables, but that's a non scalable ugly hack. What you want is easy to do if you have VLAN support on your switches (or at least they happily pass VLAN tagged packets) Enable a VLAN in Unraid network settings. Make sure not to add an IP address to the new VLAN. (this will create a new network interface eth0.2/br0.2 for VLAN ID 2. Configure pfSense to support this VLAN (DHCP, DNS, gateway). Connect a VM to this network interface. the VM should then get a DHCP IP from pfSense. You can then firewall the IP/Subnet as needed.

One way to do this is to configure Unraid to enable VLANs on your NIC, so it will create an interface like eth0.2/br0.2 (VLAN ID=2) Then make sure the configuration for the VLAN interface does not have an IP address (Most people assign an IP which may prevent this solution from working) So the VLAN is also configured and routed by pfSense (ie, the VLAN is a subnet, and pfSense has an IP in that subnet - probably acting as DHCP/DNS server as well). Finally the VM is connected to the VLAN sub-interface eth0.2/br0.2 - it ill get an IP on that VLAN and pfSense can route and filter traffic to and from that IP (or even the VLAN subnet)

This seems to be caused by the simple fact that there is no DHCPv4 client running in any container. Add to the fact that usually userland processes are not allowed to touch the network settings of the container, so the engine has to assign the IP (or the container specifies the IP to be assigned. I guess that its possible to have a DHCP-like plugin to the docker network system, but the developers were never interested in developing such a plugin. In IPv6, the same is in effect with the exception of the fact that SLAAC is configured at the kernel level, so the container can auto learn and set IPv6 networking, but again, DHCPv6 also doesn't assign IPv6 addresses to containers. Still won't work as the container engine does not actually consult with what's on the LAN and just obeys how the docker network has been configured.

No idea as I don't use that particular docker. I'm guessing the config is tied to the hostname, so changing the hostname probably caused the settings to be forgotten.

I've run various VMs under Unraid and I've never seen an issue (Windows 10, Slackware Linux, Apline Linux, Debian Linux, CentOS, MacOS Mojave and Catalina). Granted I've only started using the Linux and Mac ones a lot more since I upgraded to an i7 from a Pentium (I only have two cores initially) and they are used as test network devices, not HW pass-thru or similar. I've run crazy network instances on docker and its just usually a mix of arguments you need to pass to the docker run command and setting the hostname is just adding to the Extra Params --hostname name.domain This your great google fu should have found easily as its a very basic docker topic https://docs.docker.com/engine/reference/run/

If you don't want to troubleshoot a lot - stick to the latest stable release 4.4.0.40 HW accelerated transcoding has been there since 4.0.0.0, but its a premium feature ( you need to subscribe ) I'm not too sure about Radeon cards, but Quadros do work , though I am only using Intel iGPU for this as its cheap and more than good enough for me FYI I'm on a Mini-ITX board and have a HBA installed so can't even install a GPU

I've been on the beta since the HW assisted transcoding became a feature. Haven't really had issues like you described

I guess its technically a never seen limitation as most users either upload files via Samba; do OS level disk to disk; or download the files from the internet. So I guess you should submit and Feature/Enhancement request in the correct board, and enable manually the UTF-8 setting.

You should go to Settings | Date and Time and turn off NTP to be able to manually set the date and time. Apply. Then Re-open the date and Time settings and turn on NTP. NTP doesn't work if you have a very large gap in time (or the date in this case)

Disclaimer: My VLANs are isolated and only the router bridges them. I don't give Unraid additional IPs to muck up accesses. (this is a side effect of the older network setting where assigning the container to the same interface as the host and giving its own IP isolates them) Have you tired to access the container while its connected to the regular bridged network same as the untagged VLAN, yet using the VLAN30 IP? I mean while the VM is reachable via 192.168.1.10:2345, try reaching it via 192.168.30.10:2345 as well. I distinctly remember docker actually running a proxy that bind on all the IP addresses on the host then forwarding the connections to the container in the internal docker bridge.

Check your system clock if its correct, and make sure its date is not in the past

That's my actual solution to the situation as it guarantees the correct permissions on the OS layer. But I understand you can't turn that on users with older data and managed permissions. I'm guessing this can be a Unraid setting, but users should opt-in, unless its a brand new OS config. FYI a lot of NAS use something like that setting to make it easy for the files to be managed, even after migrating the disks out to another OS.

hmm. redoing the keys is not a real solution. I can only guess something happened on your backup server ssh files to change it. but do this main+~# cat /boot/config/ssh/known_hosts | grep bakup_ip backup_ip ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBGiAoa1bxGekGXAP+HA8pzHZ0qerF5Cy2KHuZdQF43zE02m9Op0BylDzrGiq0iek5AvpyUetp6yrmHJGSJNGfzw= backup:~# cat /boot/config/ssh/ssh_host_ecdsa_key.pub ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBGiAoa1bxGekGXAP+HA8pzHZ0qerF5Cy2KHuZdQF43zE02m9Op0BylDzrGiq0iek5AvpyUetp6yrmHJGSJNGfzw= root`backup if they don't match at any time, something changed on your USB and you can check on the running system as well main:/root/.ssh/known_hosts and backup:/etc/ssh/ssh_host_ecdsa_key.pub Not a super paranoid guy, but if the Remote host id changed, i would not have recreated the keys right away and done some investigation, because the remote host id doesn't change unless some files are dropped from the backup USB for some reason. or someone gets in does something. maybe check if the time stamps of the ssh_host_*_key files are correct/expected vs when you upgraded and the other files in that directory. Finally... not all your go lines are needed... you either don't need the pub file on the backup, or you use the pub file to create the authorized_keys file like Hoopster's