PeteAsking

UniFi Network Application 7.3.83 has received multiple patches over the last 3 months and should be considered the "best" latest version for anyone who does not require a legacy version such as 5.14.23-ls76 or 6.5.x for older hardware. So if you are on tag 7.2.95 you could upgrade to this 7.3.83 tag safely I imagine. Current situation: Legacy systems: 5.14.23-ls76 or 6.5.55 versions seem fine. (AKA "old old old stable" or "old old stable"). Wifi6/New Deployments: 7.2.95 or 7.3.83 tags are fine. (AKA "old stable" or "stable"). Do not use tag: "latest" unless you are an alpha tester who fixes their own problems. Posting this info because of the upcoming next release (7.4.x) AKA "alpha" Kind regards Pete

I mean on the unraid server itself. Im wondering if you used like 85% of the ram by allocating it out or copying a large file to the server (ram is used in file copies then written to disk after) and the OOM killer ran and ended a service that should not have been ended.

What amount of memory is typically in use at that time on your server? Was it high?

@3x3q could the above have happened to you?

What if the usb disk was disconnected during the time for any reason this happened so unraid could not write to the usb that there had been an array interruption? What happens then - ie all is perfect, usb becomes inaccessible (same thing that drops disk?), issue occurs then reboot?

It is interesting that you say this because if you download the diagnostics of the reddit users post I posted earlier on the domains.cfg file it states: shareUseCache="yes" I imagine as opposed to "prefer" Unsure why.

Not sure but another scenario I am thinking of as it happens sometimes after a power failure is that something has happened between the state of the machine when it was powered on and after it got rebooted due to a power failure. I am wondering if a common issue on the forum where a bad cable causes a disk to drop off TEMPORARILY could be something like this: 1) Unraid is functioning normally 2) A bad cable causes a disk to drop off the array temporarily (this could occur after the mover begins moving the file and is mid way through moving?). 3) A mover is invoked and it moves a file from a cache drive to the array that is now enumerated. The file is removed from the cache and the file is assumed to be on the array. 4) Unraid is rebooted due to some event (power failure, user intervention etc). 5) The disk comes back online as it was a temporary fault. Unraid starts the array? Unsure about this part. Possibly required manual intervention here? 6) The changes that were being enumerated on the parity disk are lost as now all disks are available so there there is no enumeration taking place. The file that was moved to the array no longer exists. Thoughts?

I understand the intention of the mover, but as nothing is perfect it may be possible for an unimagined scenario to allow a file to move that should not have been possible. Ruling this scenario out without rigorous and detailed mathematical proof it cannot be possible ever seems strange to me.

A reddit user here has had the same issue occur: It also happened after a power loss, so while filesystem corruption is possible it seems like something additional must be needed for the failure to occur. I also agree that its possible the mover has something to do with the scenario as it is directly manipulating files, possible during or around the time of power loss. In linux it is possible to delete a file in use as it does not actually remove the file, it just reduces the inode count by 1, and when the inode = 0 then the file is freed up from the filesystem. This can explain why user @3x3q was able to have a running VM with no file (but the space was not freed until the process holding the file was ended). If 3x3q had used the command "lsof | grep <name of missing file.qcow> most likely he would have been able to find the file and copy it to a new location using the "cp" command from /proc. Its possible this may have saved the VM if he had done this before turning off the VM. It would be interesting to see if the disks used by people with the issues are similar. Just adding this here as the number of reports is somewhat higher than random chance would suggest it should be. P

Their logic is they said one time dont do this, people did it and found it worked, so they feel they have no obligation to help. Same for unsupported devices. They have said dont do it, dont upgrade. If you continue to do it and it causes some fault, then dont expect any help from them. in addition expect them to actively try break something...

I think a lot of us have been surprised that updating the controller software can break devices or stop them working, and that you have to check your site before running an update to see if its compatible. Its actually quite tricky to know because some changes fly under the radar. On one hand the hardware is excellent and works reliably and well, and is cost effective. On the other had the software controlling it is very dangerous in a business setting to just blindly update. Its really a shame because unifi let themselves down and it reflects badly on their brand.

Also dont forget ‘obsolete’ just means unifi one day decided they dont support them. It doesnt mean they are broken. Most times the hardware is still reliable and fast enough for daily use. Sent from my iPhone using Tapatalk Pro

The problem is - as we are finding out realtime - is that unifi simply turn around one day and break it by design and when you ask why they say “well we said nobody was supposed to do that and they ignored us so now we changed it so that the devices no longer function”. So your strategy is simply a ticking timebomb.

I think we have various situations here and need to ensure we dont forget what has happened. Please double check what I am saying but I believe: 5.14.23-ls76 = This is the best version if you have old devices that Unifi have decided to no longer support in newer versions of the controller. EG: UAP-LR 7.2.95 = This is the best version if you have devices Unifi have decided no longer need to receive power anymore but dont have older unsupported devices. 7.3.83 = latest version that seems totally stable and fine, but has dropped support for old models and no longer allows certain devices to be powered in certain configurations (seems this wont likely change going forward). So problem is becoming that the 'best' version is situational depending on devices and setup at site. Since we cant know what configuration and hardware people have, they need to start checking prior to updating what tag is applicable for their hardware.

Strange because someone even posted a graphic showing that the AP was compatible with that switch to be powered. Sent from my iPhone using Tapatalk Pro

Also I think we have to ensure people stay on 7.2.95 and dont upgrade further until we know for sure what the final answer is. Either that is a final version for some people and they need to know it or there will be a fix and everyone can hold off until the fix comes out. As long as Jonathanm does not change the recommended post in this thread we should be fine hopefully.

Wow that is incredible to read, are they actually going to fix it? Reads more like "why did you do this thing? You are not allowed to do thing. Stop doing thing and buy new hardware for thing."

Also can you link the forum post where people are complaining?

This is unbelievable and shocking they would do this. No matter how much testing we do and how careful we are unifi always find a way to cause some sort of issue. So what do you do now? Never upgrade again?

No but you have to be patient. I only have 5 devices in my home network. 1 switch and 4 APs.

I applied the update successfully. The steps I took were as follows: 1) restarted docker to clear any potential issues and memory etc. 2) logged into unifi app on my phone to check it still saw all my devices prior to upgrading. 3) changed tag from lscr.io/linuxserver/unifi-controller:version-7.2.95 to new tag lscr.io/linuxserver/unifi-controller:version-7.3.83 4) waited for update to apply. On docker start I logged back into the unifi app. Noted all devices had to readopt (normal experience). 5) after about 5 minutes all my devices had readopted. Everything appears to work as expected. If anyone else would like to try a similar procedure and provide feedback for others that would be helpful for everyone thinking of upgrading. P

I have a schedule to upgrade to 7.3.83 tomorrow as it seems alright from what I have read. If you are patient you can wait to see how my upgrade goes before applying 7.3.83 yourselves. P

I found crafty 4 used more CPU resources and RAM than this pure docker alone. I ended up just putting each copy of binhex-minecraftbedrockserver on their own individual IP and that allowed me to port forward just fine from my firewall.

In case anyone needs to know the mobile app is now available on the app store for ios and is called “shinobi go”. Many thanks - P Sent from my iPhone using Tapatalk Pro

Thats for a windows machine my dude.