apandey

You are mapping host port 5012 to container port 5000 You are specifying the host port here, but this is a file mounted inside the container and likely used by the container to bind the process running inside the container. You very likely need 5000 in the config file

I run a wud (Whats Up Docker) container, which allows me to list all updates. It has view to group my project label, which is how compose organizes stacks, so I just go in once in a while and update stacks that are showing updates wud has a lot of configurable features. I use notifications and rate limiting for checks. I think it also has means to auto update, but I dont use that, as I prefer to click update stacks button after being notified. That way, I know if something breaks and can be correlated back to this update. Wud also allows version pinning or regex matches to calculate updates by applying a docker label, this allows me to not be nagged about images that I want to stay at a specific version or range even if new updates are available Details: https://getwud.github.io/wud

I am currently running 22 drive server, 16 connected via a LSI 9300-16i and the rest via the motherboard I want to upgrade to LSI 9305-24i, to simplify the install, and to reduce some heat / power (the 9305 is a single chip controller, while 9300 is 2 of them slapped together on a PCB) My only concern is that if the new card isn't good, I may run a risk of corrupting my drives when I swap. What can I do to test / verify the new card before it can start writing to my drives? Is there a safe way to do the switch?

I have a mix of dockerman and composeman managed docker containers on my unraid Running unraid 7.2.0 wherein unraid should not be checking for image updates for composeman managed containers, which largely works ok, except for 1 odd container, where I see this: in here, unifi-network always keeps showing as update required, even though it is managed by compose. the actual image is up-to-date via docker compose. This container, like many others on my server was migrated from dockerman to composeman, but this particular one has got stuck in this wierd state I have tried to remove this container (compose down) and reinstall (compose up), but that still comes back with same state Any suggestions on how I can clean this up?

I believe this is already shown. example screenshot, see first column, right below container name and status

It would be even better if we can choose a set of docker labels to show in docker tab. I currently run a wud (what's up docker) container to keep track of my containers. It allows me to view and filter, and I can group by labels, so doing so my compose project label gives me the split out view. I mainly started using it to keep an eye on updates across dockerman and compose

yes, been there and done that. Unfortunately, it's a black box and I am more comfortable with gitops approach for config management where I know what is applied and can debug / change it of its not to my liking. Also, it unifies install / update and restore all to a single process, so I don't have to rethink when it comes to such infrequent maintenance. Personal preferences I guess I do have appdata backup runiing to take nightly backups along with all my data. But thats more of a fallback for operational errors rather than for data backups

Seems this involves re-installing the templates from previous apps. I was on a journey switching my containers to docker-compose, so I would first finish that migration before switching over. that way, all my state can roll out from a git repo via ansible

Indeed, I don't want to bother when I know where the space is going. I wasn't aware that I can use a directory instead of a disk image. Will certainly help and be simpler. Will look to switch to this and report back. Thanks a lot for the pointer

I have a 100GB docker image disk right now. As I have added more containers, I have had to iteratively increase the image disk size. This is not a misconfiguration, containers are not being written to to contribute to the size. The size is mainly coming from the docker images themselves - I have multiple ML images with models etc which are 5-10GB each adding up quickly. While updating versions, having 2 copies gets docker image into high utilization warning zone I have been increasing the disk image size slowly, adding about 10-20GB in each iteration. Is there any downside if I gave it a large headroom and not worry about it for a while? In other words, is making it 200GB OK without any side effects? I keep an eye on growth and any write activity into containers separately, so I am less likely to not notice a misconfigured container that eats up space via writes into the container

I version control both the stack files and override files. There is nothing in the override file that is dynamic, it can always be applied from a vcs copy. I am using the `plugins/compose-manager/project` folder and roll out my vcs content via ansible. works fine so far

Extended smart test was ok. Rebuilt on top, which also went fine. Been ok for a day, so all looks ok I'll get to log spam separately when I get a chance

Thanks. contents look ok. I cannot physically access the server and swap cables right now, but I have started an extended SMART test before doing the rebuild log spam, I am not sure what to do there. But will swap / reseat connections when I open up the server, perhaps over the coming weekend

any further suggestions from anyone?

rebooted, started array. please see diagnostics after array start godaam-diagnostics-20250327-2110.zip