Ryoko

Aside from what the others have suggested, I only make sure I have the flash backup on a separate PC just incase I need it. Follow any of the release notes instructions. I generally ensure all my plugins and dockers are up to date and go for it. Afterwards, I go through the system log and make sure there are not any new or weird errors. That's pretty much it for me, but hope that is helpful to you.

Updated both servers from 6.11.5 to 6.12.5, then to 6.12.6 without issues.

I fought for 2 days with Syncthing and my phone (was thinking it was a Syncthing issue) trying to get passed some permission denied issues. Noticed the files and directories this would make were all authored as UNKNOWN. Ultimately I just ended up installing it via the Obsidian official windows installer into my VM, no sync or permission issues after that. I love the idea of running it in a docker though.

My apologies, not sure why it didn't work yesterday, but I tried again this morning and had no issues! Probably something was just funky with my PC or Chrome Thank you though for responding! @Djoss

Update- Seems to have been an issue with my PC or browser. Had no issues with it today. Unable to type, nor paste Japanese characters into the search bar while looking for a file to restore. The file names all show correctly in Japanese, but I would like to be able to search them in Japanese as well. Am I missing something? Am running on Version: 6.11.5

I don't know if this "the right way", but I got to the odoo webUI doing the following. Hopefully it is helpful to you or someone else, and it's here for me when I need it later ^^; Reference per @Thomasg - "Used the sauce from : https://registry.hub.docker.com/_/odoo/" Firstly, install PostgreSQL 15 via your unRAID Apps and set as follows... Name - db <---- per the reference "The alias of the container running Postgres must be db for Odoo to be able to connect to the Postgres server." POSTGRES_PASSWORD: Set a password you think is strong, I used a 16 chars alphanumeric from a rnd generator POSTGRES_USER: odoo POSTGRES_DB: postgres Next, install the Odoo15 from your unRAID Apps and set as follows... Addons: /mnt/cache/appdata/odoo/extra-addons <--changed these to /mnt/cache/appdata/ to hopefully keep it all in an easy to find/use space. Configuration: /mnt/cache/appdata/odoo/config <--changed these to /mnt/cache/appdata/ to hopefully keep it all in an easy to find/use space. DB Username: odoo Database Password: Previously entered strong password from above Database URL: your unRAID server IP And that seems to have worked for me. Hope it helps o/

I'm not sure if this is relevant to the OPs issue or not, but right now, my current work around for naming IPs over WireGuard, is just to add the record to PCs that we use remotely's Windows Host file. It has no problems pulling up network mapped drives, etc. when done this way. I'm sure there has to be a more elegant way of doing this though, maybe in the wireguard config file?? It seems that everyone is just forwarding to either piHole or pfense though, as everything I Google to try and find an answer, relates to those. If someone knows how to do this directly in the Wireguard config files, that would be greatly appreciated. (note) networks are multiple unifi usg3s, using jsons directing the naming across IPSEC tunnels. Changes to those break that functionality

Thanks, that fixed it! Now when I open the Plugin tab, it checks the status.

Updated the office server from 6.8.3 -> 6.10.2, seems like no issues so far! UPDATE- Couldn't get the VM to reboot without black screening the system, ended up bonding the GPU and USB Controller via the VFIO-PCI option in System Devices. This fixed that issue. Also was finally able to remove the "Docker - Case Insensitive" fix from the go file. UPDATE 2- In the Plugin tab, they show as status unknown everytime, until I click check for updates. Solved by this .... Final issue being, Nerdpack is showing "kbd-1.15.3-x86_64-2.txz" and "mcelog-161-x86_64-1.txz" as being "update ready" even though neither of those exist on my flash device under the 6.10 nerdpack plugin folder.

Stop and edit the docker. Change Repository: to this... linuxserver/openvpn-as:2.8.8-cbf850a0-Ubuntu18-ls122 Click Apply and it will rebuild the image You should be good to go after that once it finishes loading up o/

Unfortunately I tried that as well as connecting from differing machines that normally do not have access. No joy. I ended up reverting back to 6.8.3 due to other issues, but won't be able to mess with the docker till next Tuesday. UPDATE (solved) - Seems to have been a corrupted image. Moved the appdata to another share, removed the image, reinstalled via template, copied the appdata back over, used the controller's autoback file from the beginning of the month to restore everything. 100% back up and running.

Updated unRAID 6.8.3 -> 6.9.2 and now get a "ERR_CONNECTION_REFUSED" when trying to access my unifi 5.14.23 docker webui. The docker log shows no errors messages. So I tried: removing and redownloading the docker, completing deleting the docker image, reverting to 6.8.3, etc. Tried playing with the webui ports in the docker, but it just spits out the same error. The tunnels I have to offsite USGs are still up and according to their webui's, "The UniFi Controller is currently unreachable." TBH, not sure if this is a 6.9.2 issue, or an underlying issue that happened to pop off when I tried the update. Has anyone else run into this or has a suggestion on where/what I can try?

Out of curiosity, which video did you find? What was the exact solution for your problem? I am also having a similar issue, worked fine in 6.8.3, but not with 6.9.2 @awediohead

64GB 3200 non-ecc

Japanese would be greatly appreciated as well.

Thank you for this!! I can confirm this works and got Manjaro 18.1.5 KDE Plasma running using binhex's method.

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

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