NLS

It is just a "follow" on that being a file. I use the path you propose for more than a year, so you do it also, don't worry about it.

But this is dead I think. The one working now is binhex-crafty-4.

That was a bad misquote. I wasn't the one I said that it is a risk, I said the opposite.

Not really. It depends how the open ports are handled.

You can definitely mathematically know if you can have a solution. You can calculate in advance, taking care of OS intricacies. All these things are documented. The process might get just a bit more complex, but that is why we use computers, right? Anyway, I am showing a "probable" way to go. Just that. Now about your PS. I have at times thought of "why bother, just let everything mix" etc. My take is that UNRAID's parity method (which is a type of RAID4), can have advantages to harness. Knowing (roughly) what is in every disk is an advantage in case disks die OVER the number your parities can save. If that (knock wood) ever happens I definitely prefer to know "I lost my MP3" or "I lost that piece of my emulation data" etc. instead of "I lost probably a piece of everything". It is of course a philosophical matter in the end. This also helps with local backups (I use that). I make sure that for things that are too important I daily sync some specific folders to two different disks (while using those disks also for other things). If I didn't care about all that, I might just use a "normal" RAID5 solution. Anyway, I hope all this discussion evolves to something interesting (a future plugin?)

Try this link? https://docs.google.com/spreadsheets/d/e/2PACX-1vSyL6hHkrzSQwik_tpBfTc_6cEMogKQAKzpB5YUkuimqnq8d92hbUUcXQeiWIU1Kfszrq7vKuDPvTld/pubhtml (else I need you PM me your gmail)

So I am thinking of REALLY merging my top level folders as much as I can (I have a whole plan) after years of spill-overs. You know what would take "unbalanced" to the next level? Really automatically make and handle a plan of shifts to arrive at planned "end shape". An unbalanced "2.0" would do it for a single folder. In other words "I want this folder" (which could be a full share, if it fits) "in this disk". But that destination disk has things that make it NOT fit. Then the user will be able to select folders in the destination that doesn't want touched (moved). Then the system will make a quick check if folder to move there + folders that user doesn't want to be touched, fit that disk. If they don't allow the user to modify locked folders or select different disk or whatever. If they fit, then supposed unbalanced 2.0 will decide the moves that need to be done OUT of the disk (keeping top levels "together" as much as possible) and in the end (OR IN SMALLER STEPS if there is not enough contiguous space - this is the whole point of needing such an app) reach the point where locked folders are still there, folder to be moved has moved there and everything that doesn't need to move out is still there and what needed to move out is on different disk (even on the source disk that the folder the user selected moved out of, that now has more space) as much kept together as possible. This would be magic. Let me give an example with three disks in a google sheet... https://docs.google.com/spreadsheets/d/1GApW5mRgftP0FmUmFbbsO-nsn0ZjohbIjvO6FJz-y_g/edit?usp=sharing Version 3.0 would make this for multiple folders (this in disk 1, that in disk 2, the other in disk 3 and so on) and make a whole plan of moves to reach that destination. Or even handle organized "spills" (like this in disk 1 and rest in disk 2... which would be "Videos" in the example). I can possibly help analyzing the logic (maybe pseudo-code, my original background includes development - but have it "semi-forgotten" over the years, working in different fields of IT).

Yes. On the other hand, getting support = getting lucky, when self hosting and open source. As for this container, no you are wrong. Last update was last summer (less than 6 months), which is "okayish" in my book. On other news, I was forced to delete my docker folder and reinstall everything (where everything = 42 containers ...) because a couple got messed up last night... Couldn't start, couldn't be removed... Even using portainer... Anyway.

Thanks - but no thanks. I moved to another that is self contained. That said, if I get more containers that need a stand-alone DB, I might revisit.

Guys I have the container for long time, update it regularly (when there is an update), but haven't run it for a couple of months. So now that I start it, I get 500 error. What died?

How do I get rid of it? It is KDEinaDocker. During update today, I noticed that it failed because "a container with the same name exists" (erm... duh!?). So I tried to start it afterwards, no go. Tried to remove it, no go! Even portainer cannot remove it! (but did rename it to KDEinaDocker-old) Also stopping docker service and restarting it, didn't help. Note my cache disk is zfs. What do I do?

I've been using UNRAID for years. I see that it is not installed. Anyway, using the direct URL also did nothing (!!!)... So I rebooted the server once more. I will try again from apps and see what happens: ...and yes... now I HAVE unbalanced and configured port and enabled it! Nice blue interface.

It was tha latest. In any case, now the problem changed. I rebooted the machine to see if this "already in progress" unstucks... ...and it DID unstuck! I clicked install... it said it installed fine. ...but it didn't. I couldn't find unbalanced in the plugins! So I go to apps and I see it still shows "install" (so it doesn't detect that it is installed). So I click "install" again... ...and it does nothing!!! (btw I noticed the new plugin uses a different port and that different port is not even configurable? So how does it know that there is no conflict???) Remember I use UNRAID for years and I have numerous plugins and containers and VMs on it. At this point I cannot reboot the server again, maybe within the weekend. Any ideas?

Well I cannot install, because I removed old plugin, it got removed fine, then I click to install "unbalanced" and it says "Installation already in progress" (which is not true)... Some flag is set somewhere? Some service shouldn't be running?

fixed itself after reboot if I remember

I can reply to my own bonus question: If I edit the template and change default app data path to the correct one (i.e. /mnt/user/config to point to /mnt/user/appdata/technitium-dnsserver/config/), then I can add an extra path (I named it app data 2) and point /mnt/user to /mnt/user/appdata/technitium-dnsserver/. This solves the issue and the container can now auto-update! (if I don't add the first path, the container doesn't assume that /mnt/user/config is under /mnt/user as it was supposed, but instead does NOT make it a bind path at all and points to the wrong path). MY SOLUTION DOES NOT SOLVE THE BUG THOUGH! This is why I don't close this report. I mean, I corrected the issue, so I don't hit the bug, but the bug is still there and can probably hit others. The bug is that if container after update has an issue, something removes it from the container list! I suspect the coolpit is somewhere in the update script where the script removes the "old" container, before verifying that indeed the "new" one can be deployed. If the deployment fails, we are left with a removed container!

Then 10 minutes is definitely too much.

All of a sudden, this is how it looks. ctrl-F5 or different browser, didn't help. Latest UNRAID version, everything updated.

You mean to start? What is your RAM and CPU?

Seemingly the worse of the issues (containers not running) is my fault. I messed appdata persmissions...

I tried adding a new container and that worked. ALL old ones show "bad parameter"!

So I have set a few UNRAID, with my own counting (way) more than a decade. Never seen that before... The server in question is for a friend, I've set it up months ago (maybe a year). Hasn't happened to it before either. Server went down ungracefully, because of a power outage beyond UPS capacity. Normally this is no issue, system does an extra parity check and all ok. And indeed they were... Except people in that SOHO noticed the main share was not working any more. Quickly I noticed I could access it ok using IP instead of hostname, so I gave them that temp solution. Then SOME discovered they couldn't WRITE in the share! Then I went deeper to see in UNRAID what could be the issue. Server seemed to run ok, latest version, everything mostly updated, containers (very few) and VM (a Win11 that needs to run a couple of Win-only things) running ok. Since this is a SOHO, there is no real granularity in the access of the main share, it is set to private, but read/write for both the "advanced" user (the owner) and "user" (the rest of them). This is how it was always. First thing I noticed which is WEIRD, is that server changed back to default name "Tower"! First time I've seen this! This explained why they didn't see the server as it was not named as expected and mapping didn't work! Then I noticed that even the VM couldn't write to the share (although able to read it). I was forced to switch the share to "public" instead of secure! After I stopped array and changed the name back, I rebooted (gracefully this time) the server and thought everything was ok now. But after the reboot NO container starts (although docker is running), with "bad parameter"!!! The last thing is the worse! I am not sure what to do!

Please implement "implicit no" (i.e. default auto update to yes, and set one or a few specifically to no), for auto updates. Right now, you only have "yes" (which cannot set one or some to no), or "no" (which you can manually set few to yes). It should be "default yes" or "default no" and in both cases allow to change some to the other option. Thanks.