JasonJoel

Too late for that. No updates in 2 months <> soon. But it will be done when it's done, I guess. By definition. My data, and uptime on the system, is too important to me to run pre-RC betas. So I'm just getting impatient. Lol

Probably. But I don't think we should be making general recommendations for users to use beta software releases. And further the beta hasn't updated in over five weeks, and it has plenty of known issues... Not sure I would recommend someone jumping over there just yet.

+1

+1

Wow, awesome! Thanks!!!

I did remember that but thank you for the reminder as that isn't very intuitive/obvious!

Putty it is then. Thanks for your help, as always!

I actually forgot that was adjustable. 😫 I put the container last to buy more time, but I haven't tried increasing the delay. Duh... I'll try that next.

Very true, and I can certainly do that. It is just to tantalizingly easy to click the terminal button when in the interface, though. To your point - putty is a fine workaround if it can't be changed.

I thought it might be that.... If I remember correctly I created it on the console of the unraid server, than I added this to my container as a post argument: "; docker network connect --ip 192.168.2.252 br3 avahi" I need the docker to talk to 2 networks (the whole point of the mDNS reflector), and couldn't figure out any other way to bind the container to 2 networks.

I guess I'm getting old... I simply can not easily read some of the text on the unraid console when I get in there. The green background highlighting with blue text messes with my eyes. Is there any way to change that? Example, see the text on the directory listing:

I have one docker container that will not start after a reboot. Every time, I have to go into the container, edit it, change something (anything) and hit Apply, then it starts and runs just fine. It is the only container I have that does that, and I'm struggling to understand why. It isn't the end of the world, since a simple edit/apply fixes it until next reboot, but it is just weird. The container in question is named "avahi". As you may guess, it runs the avahi mDNS reflector service. unraid-diagnostics-20191231-1720.zip

Well, the plugin says to post questions here, so I did.... 🤷‍♂️ Attached. Thanks! unraid-diagnostics-20191231-1720.zip

Every reboot I get the following warning in FCP. I then do Apply Fix, it says 'fix applied successfully', and I go on my merry way. Next reboot same warning message. Is there any way to stop this permanently?

Understood, and that's what I did - no issues. Thanks for maintaining these great plugins!

Awesome, and thanks. I use this container for a bazillion things, and very much appreciate you maintaining it!

Stupid question @cmccambridge.... The community apps version of the container is 1.5.8... But I see the current version on your github is 1.6.x. EDIT: Never mind. It looks like when it installed originally the repository was listed as "cmccambridge/mosquitto-unraid:1.5.8". I changed it to "cmccambridge/mosquitto-unraid:latest" and all is good.

I use a SUPERMICRO MBD-M11SDV-8C-LN4F-O on my Unraid server. Epyc 3251 based. Works fine for my use (10 docker containers, 3-5 VMs, file server). I don't have any comments on 10GB ethernet, as I see it it as a waste (for my home use) until the switches come down in price.

I am surprised parted was moved to plus... Seems like anyone that mounts drives will want to format one sooner or later (?).

It looks like the issue was indeed on the Allowed IPs on the peer side when I set it up via the QR code. I guess by default it only adds the subnet the Unraid server is on, and its 10.253.0.1 tunnel address (which makes sense). Thanks for the pointer on Allowed Peer IPs!!! I didn't think to check that on the Android/peer side...

Hmm... Good question, I'll go through it again tonight and double check. Entirely possible it was user error.

That's what I have to do every time I want to stop VM manager. Edit domain.cfg, reboot, make changes, edit domain.cfg, reboot. Kind of annoying, but it works. Not like I make those network type changes daily, so I live with it.

I did get it to work - kind of. I could access anything on my primary subnet (192.168.1.x) which is the same subnet my unraid server is on. But I couldn't ever connect to anything from any of my other subnets. Didn't see the traffic at my router at all - so I'm not sure the bridge is routing traffic from other subnets (?) up to the router. I tried turning NAT on/off, no difference. Works fine w/OpenVPN, so back I went. I will say that wireguard was fast and connected quickly for those nodes on my primary LAN. Very cool - just wish I could get to my other subnets. Untangle is going to add wireguard support, too, so I may just have to wait for that, as theirs will support multiple subnets/routing.

So what is the verdict - can you use WireGuard if your Eth0/Eth1 is in a bond, or not (for Remote to LAN type conections)? I would rather not disable the bond, as I regularly go over a single 1Gb connection of bandwidth when doing backups on multiple nodes. Thoughts? My network connections today: Eth0/Eth1 - bonded, bridging = false. Eth2 - VM/Docker LAN connections, bridging=true Eth3 - VM/Docker IoT connections, bridging=true

Upgraded from 6.7.2 - no obvious issues. Thanks!