ryoko227

Just a gentle reminder, the support link in the docker tab still takes you to the incorrect forum link listed above.

^ agree with everything above. Unifi is the one docker I never rarely update, it just sits there staring at me. Watching the utter S-Storm when new "updates" (if you can call them that) come out over on their forums. Awesome hardware, terrible (most often broken) software. Still sitting on 5.8.3 since that's the last stable I've had 0 issues with. Love LIO for their hardwork trying to keep everything up and running though for us. o/

Not sure if I'm the only one, but when I click support in the Docker drop down menu, it takes me to the old support page located here https://forums.unraid.net/topic/41631-support-linuxserverio-openvpn-as/ Just a heads up

^ that is basically what I ended up doing. Luckily I can pass through the USB controllers on my MB. Never any issues anymore.

Home Server running AMD 1920x updated from 6.6.7 => 6.7.2 with no issues or modifications needed o/ Thank you as always!

Couldn't update to 6.7.0 without hosing my system (in that update thread). Decided to try again adding ... iommu=pt before updating to 6.7.2, and was able to move over with no issues from 6.6.7! System seems snappier and looks great. Happy to finally be on the 6.7.~ line. \o/

Oh, dang, I was hoping for some juicy tidbits, sorry for the confusion. Thank you though, I can also confirm that the APs don't seem to have any issue when “Override inform host with controller hostname/IP” are with the FQDN, just the USG that's WAN IP is where the FQDN resolves to. I'm gonna see if I can find a way to json the inform information and hard lock them to something that works. ---------SOLVED---------- https://www.reddit.com/r/Ubiquiti/comments/bxrzoh/usg_setinform_fqdn_gives_local_usg_adopt_loop/ This is how I made the config.gateway.json... { "system": { "static-host-mapping": { "host-name": { "FQDN": { "inet": "My_unRAID_Local_IP" } } } } } Since it's running in unRAID, I could simply place this into... /mnt/cache/appdata/Unifi_Container_Name/data/sites/Site_Name_Being_Used

Sounds like something specific on my side then. So I checked the USG's config.boot and its showing "hairpin-nat enable" in the port forwarding section. I then verified that the FQDN resolves internally, pointing to my WAN IP, which it does. So I checked my firewall and porting forwarding to try and make sure I don’t have anything silly in there. Everything is default, aside from my port forwarding stuff for the inform, stun, and an old OpenVPN docker I had setup. From there I started searching and found something about forwarding ports 443 and 10443, but that also didn’t work. I even forced a DNS entry for that FQDN => local unRAID IP, which worked for all devices except the USG, which would still come back with the WAN IP, and then adopt loop. Thinking something was off, I created another docker container completely from scratch, no backup restore, set-default all devices, this time using 5.8.30 on the controller. Same issue, if I don’t “Override inform host with controller hostname/IP” when the docker/unRAID server restarts, the devices go into an adoption loop. One thing I did notice that I thought was odd is if you SSH into the devices and use “info” while its looping, it’s showing an inform set to the docker container IP, not the previously set/working inform information. I really don’t have any idea why the USG isn’t liking the FQDN as its inform. I have pulled power, set-default, used the reset button, everything back to factory, and it still hates it. If I set-inform to the local unRAID server address, it immediately connects. Did you have to do anything special to get your's working with an overiden FQDN? Outside of that, I am extremely curious if there is a .json way to hard-lock the inform information on a per-device basis. That's kind of the last ditch effort , as this is looking like my only/easiest option.

Coming off of the deprecated 5.6.40 controller which had no issues, now I am seeing the same adopting issues as many others have mentioned on 5.6.42, 5.8.30, etc. Unfortunately, I cannot use the "Override inform host with controller hostname/IP" work around as I have USGs in other sites that use a FQDN to inform the controller, which I have found the above workaround does not work with. Things I have tried and noticed. Override inform host with controller hostname/IP – using FQDN ・Offsite no issues connecting, local devices adopt loop ・From ^ SSH into the local devices, set-inform manually to the controller’s local IP, it will connect, then when it re-provisions those local devices to the FQDN forced hostname, it starts looping again Not using override - after restarting unRAID ・Offsite that had been set previously with FQDN inform, connects with no issues ・Local devices adopt loop. Like above, setting the inform manually via ssh to the controller’s local ip works immediately I am using a site-to-site tunnel, and according to unifi, the tunnel should auto update the WAN address, keeping the connection alive. So I’m wondering if forcing the inform to the local ip of the controller will work or not. I don’t know, even if it does, I don’t like that idea of having only a single point of failure, with the probability of loosing access to that offsite site. I’m curious if maybe making a json file, setting the local device’s informs to the controller’s local IP address, if that will be like ssh’n into them manually stopping the loop or not. Just an idea that popped into my head, but I wouldn’t know how to do that, even following the unifi “make a json” instructions. If anyone has any other ideas, I am open to them. Otherwise, I might have to try and get the 5.6.40 controller back up and running again (if that is even possible with it being deprecated). Updated---- Tried rolling back to 5.6.40, same issue there now. Not sure whats causing it. I mean, everything still works (aside from the controller) after a reboot, so I suppose it will just be a minor annouyance of manually set-inform'n for awhile until things get sorted out.

Unfortunately, upgrading from 6.6.7 to 6.7 grenades my unRAID. In reference to the system in my signature named Yokohama Server, after updating I got something similar to... DMAR:[DMA Read] Request device [04:00.0] fault addr DMAR:[fault reason 06] PTE Read access is not set can't find bond device. It assigns the server a completely out of range IP, and the webui isn't even available via the GUI boot option's localhost. Thinking this is an issue with IOMMU based off previous posts, I decided to try rebooting with VT-d disabled in BIOS. Server came right up, no errors in the logs, no issues at all (aside from not being able to passthrough devices to my VMs). I checked with MSI, and they haven't released a new BIOS for this MB since 2018 (already on the current version). I require passthrough on this server, so have had to revert back to 6.6.7

Sorry, quick question, how does one go about doing this? (also having the same issue as the previous "update") EDIT- I removed the image, then tried docker pull linuxserver/openvpn-as:2.6.1-ls11 Which seemed like it gave me the previous version (just fumbling about using google here). However, still have the same issue. EDIT 2- Removed that image, added the container again via the unRAID GUI, changed the repository to "linuxserver/openvpn-as:2.6.1-ls11", worked like a charm! Back up and running ^_^v

2 PCs from 6.6.5 -> 6.6.6 no issues

This is all really good info! Sorry the OP got hacked, but it's helpful to see a "what not to do" case. I tried something similar once on a test rig, dropping the unRAID IP into the DMZ.... OMG! The literal NON-STOP SSH login attempts were insane. Needless to say, that test rig got a complete wipe after that experience. Back on point though, @Abnorm I just wanted to bounce this off you since it seems related to what the OP is trying to fix and also to make sure that I'm doing this correct. I have a OpenVPN docker, with the default port forwarding setup on the router, and named via duckdns. Is it relatively safe to assume, that unless someone finds a vulnerability in OpenVPN itself, that this rather standard method should be predominantly secure?

Updated both servers from 6.6.2 with no issues to note o/

Just a follow up to this, since I thought it was weird and also so when I forget what I did I can check back later, www So I never got around to running the memtest, partially out of laziness, mostly out of not wanting to stay after hours. I noticed yesterday, that the mounting point for the drive no longer seemed to have any files or folders in it. So I tried copying the backups over just to see, and it said the disk was full... I decided I would try reformating the drive (again just to see) and pulled the mount commands from the go file and rebooted. Drive showed up totally fine in Unassigned Devices, could mount with no issues, and all the files and folders were still there. So, I set it to automount, changed my VM settings to point to this new mounting point, and profit. EDIT - Even with mutliple reboots nothing has changed... weird Everything seems to be running fine and I have had 0 checksum errors since. Keeping in mind, I did the 6.6.3 update right before all of this. So TBH, I don't know what "fixed" it, or even what was ultimately wrong with it. I know I should still run the mem test to verify