ken-ji

Sorry guys, real life's been busy. I'll look into this soon over the weekend.

Show your docker mappings here and check them for a folder named Dropbox - that sounds like the source of the issue.

I think when the thread was marked solved, we didn't have the host access setting yet. hence my comment. I think the issue with the host access failing is due to a race condition that fails on certain cases (containers starting up before networking is ready?) @bonienl would have a better idea. I do think enabling ipvlan on the latest versions would solve the issue with access over the same network interface. As for bug reports, just file one with the server diagnostics in both cases - working during startup and not to compare with.

the command to see IPv6 routes is "ip -6 route" what's odd is your router not being able to ping the docker. have you tried running a traceroute tool on your router, maybe the router route settings is not correct. or you have firewall rules? not really familiar with OPNsense

Its not immediately clear what's wrong. If you do not set a static IPV6 address, Docker should assign one - so for testing, do that and see if the container is able to ping the router and vice-versa? I assume other devices in the VLAN have ipv6 working properly?

What are you using to reach the the container over IPV6? Unraid cannot reach anything on br0, as 6.9.2 macvlan system used by docker expressly prohibits the host and container communication over the "shared" interface. Also, does your LAN ipv6 have the same /64 prefix as the container? In my case I don't use static assignments, just SLAAC, which gives me fairly static IPV6 address since the container MAC address is defined by the static IPv4 assigned to it. [email protected]:~# ip addr s dev br0 18: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 70:85:c2:4a:e1:d1 brd ff:ff:ff:ff:ff:ff inet 192.168.2.5/24 scope global br0 valid_lft forever preferred_lft forever inet6 xxxx:xxxx:xxxx:xxxx:7285:c2ff:fe4a:e1d1/64 scope global dynamic mngtmpaddr noprefixroute valid_lft 3584sec preferred_lft 1784sec inet6 fd6f:3908:ee39:4001:7285:c2ff:fe4a:e1d1/64 scope global dynamic mngtmpaddr noprefixroute valid_lft 3584sec preferred_lft 1784sec inet6 fe80::7285:c2ff:fe4a:e1d1/64 scope link valid_lft forever preferred_lft forever [email protected]:~# docker exec nginx ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: [email protected]: <NOARP> mtu 1480 qdisc noop state DOWN qlen 1000 link/ipip 0.0.0.0 brd 0.0.0.0 3: [email protected]: <NOARP> mtu 1476 qdisc noop state DOWN qlen 1000 link/gre 0.0.0.0 brd 0.0.0.0 4: [email protected]: <BROADCAST,MULTICAST> mtu 1476 qdisc noop state DOWN qlen 1000 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 5: [email protected]: <BROADCAST,MULTICAST> mtu 1464 qdisc noop state DOWN qlen 1000 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 6: [email protected]: <NOARP> mtu 1480 qdisc noop state DOWN qlen 1000 link/ipip 0.0.0.0 brd 0.0.0.0 7: [email protected]: <NOARP> mtu 1480 qdisc noop state DOWN qlen 1000 link/sit 0.0.0.0 brd 0.0.0.0 215: [email protected]: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP link/ether 02:42:c0:a8:5f:0a brd ff:ff:ff:ff:ff:ff inet 192.168.95.10/24 brd 192.168.95.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fd6f:3908:ee39:4002:42:c0ff:fea8:5f0a/64 scope global dynamic flags 100 valid_lft 3435sec preferred_lft 1635sec inet6 xxxx:xxxx:xxxx:xxxx:42:c0ff:fea8:5f0a/64 scope global dynamic flags 100 valid_lft 3435sec preferred_lft 1635sec inet6 fe80::42:c0ff:fea8:5f0a/64 scope link valid_lft forever preferred_lft forever My containers are connected to a different VLAN, hence the /64 is not quite the same. But I have local-only IPV6 prefix for my LAN for intersite VPN traffic, and the fact that my ISP gives out a dynamic IPV6 prefix the dynamic ipv6 prefix makes it hard to run docker with network settings defined, thus making me use SLAAC more efficiently - it doesn't help that my router is a Maikrotik, which has other issues with IPV6 networks (lack of proper DHCPv6)

1. This is possible. As long as the Spare interfaces are configured without IP addresses, network isolation on those interfaces is enforced, though on the IP level only 2. I rarely do it since my config uses br1.3 for my docker containers, and my VMs on br0.3, but nothing is preventing the VM and docker container from sharing the same bridge interface. My Docker container: My VM From the VM

the keytype and bits depends on your needs but the simplest command is ssh-keygen -C "comment so you know which key this is" -f path/to/private_key -m pem -N "" This creates the keypair /tmp/mykey and /tmp/mykey.pub using the rsa format (with 1024bits I think) `-C "comment"` adds a comment at the end of the public key so you can tell which public key it is later on. `-N ""` specifies an empty passphrase which is used to encrypt/decrypt the private key (This could be use to "safely" store the private key in certain places) `-m pem` is a function for interoperability of the private key with older ssh implementations (if it works without for you then you can skip specifying it) You can specify `-t ecdsa` or `-t ed25519` to use those key formats if needed.

My mistake, I'm not using any of the unraid.net services and I missed the authorized_keys files Are you able to generate logs or diagnostics from your client? I simply use the builtin ssh client in Windows, Mac and Linux all the time so I usually just run it with ssh -v to see why ssh client is being made to do password authentication.

ah. you need to rename the public key unraidbackup_id_ed25519.pub to authorized_keys then you can delete the private key from Unraid I thought you were trying to ssh to other servers from Unraid. My case uses both hence the authorized_keys and id_rsa files In a nutshell * Generate private and public keys * on the server you are going to access, append the public key to authorized_keys file, creating it if it doesn't exist. The typical location is /root/.ssh/authorized_keys * make sure the ownership is -rw------- (600)

hmm is your config file referring to the unraidbackup_id_ed25519 as the private key? by default ssh will try to use id_rsa, id_dsa, id_ecdsa, id_ed25519 and maybe a few others as the private key file running `ssh -v` will let you have an idea on what's happening.

As of 6.9.2 the only thing you really need to do is generate your ssh keys and stick them in the correct place either /root/.ssh or /boot/config/ssh/root (/root/.ssh is a symlink to this) [email protected]:~# ls -al /root/ total 32 drwx--x--- 6 root root 260 Jan 18 11:20 ./ drwxr-xr-x 20 root root 440 Jan 17 06:58 ../ -rw------- 1 root root 13686 Jan 17 11:29 .bash_history -rwxr-xr-x 1 root root 316 Apr 8 2021 .bash_profile* drwxr-xr-x 4 root root 80 Oct 29 10:21 .cache/ drwx------ 5 root root 100 Nov 30 06:02 .config/ lrwxrwxrwx 1 root root 30 Apr 8 2021 .docker -> /boot/config/plugins/dockerMan/ -rw------- 1 root root 149 Jan 18 11:20 .lesshst drwx------ 3 root root 60 Oct 29 10:21 .local/ -rw------- 1 root root 1024 Nov 13 00:36 .rnd lrwxrwxrwx 1 root root 21 Apr 8 2021 .ssh -> /boot/config/ssh/root/ drwxr-xr-x 5 root root 280 Jan 16 10:23 .vscode-server/ -rw-r--r-- 1 root root 351 Jan 18 00:00 .wget-hsts [email protected]:~# ls -l /root/.ssh/ total 32 -rw------- 1 root root 418 Mar 9 2021 authorized_keys -rw------- 1 root root 883 Mar 9 2021 id_rsa -rw------- 1 root root 209 Apr 19 2021 id_rsa.pub -rw------- 1 root root 3869 Jul 24 08:59 known_hosts [email protected]:~# ls -l /boot/config/ssh/root/ total 32 -rw------- 1 root root 418 Mar 9 2021 authorized_keys -rw------- 1 root root 883 Mar 9 2021 id_rsa -rw------- 1 root root 209 Apr 19 2021 id_rsa.pub -rw------- 1 root root 3869 Jul 24 08:59 known_hosts

the SSL port is a bit different since Unraid is configured to redirect almost all access to the canonical url (https://XXXXXXXXXXXXXXXXXXXXXX.unraid.net or https://yourdomain.tld) depending on how the SSL certs are provisioned. only https://unraid_lan_ip_address will not be rewritten (to still allow access while the internet is down) as for your SSH issue. I'm not sure since I haven't tried doing such a thing, but something to look at is the version of ssh used by your external host - openssh 7.6p1 - there might be interoperability issues with openssh 8.8, since your connection log indicates the network natting worked (client was able to ascertain the server app version) but connection was broken. maybe sshd -ddd will give you a better idea why the client disconnected.

You really shouldn't be doing it this way. And since you've happily published your WAN IP + ssh port you'll have bad actors knocking on it soon, if not already * Revoke the port forward. * See what your options are for deploying your own VPN server (Wireguard on Unraid) or maybe something on the Router (not familiar with the ASUS line) * Use that VPN to connect and login to the Unraid SSH (or Web UI) Also Unraid only allows root to login by default, so that might also explain the connection closed/reset

An alternative is to do what was done before UD: mount the drives directly in Unraid via the shell - probably via "mkdir /tmp/disk1; mount -t ext4 /dev/sdX /tmp/disk1", However, the data is only available to local Unraid processes