Kilrah

In theory yes but the process is known to commonly lead to low quality, and people to often not take the time to verify and fix that. If someone had to write something themselves they will have had no choice than to put in the effort to write it. When they use AI "just post the output, it saves me time and effort" becomes possible and tempting, and experience shows people often do that. You might not but the fact that people do means that when AI use is obvious there will always be an amount of suspicion and lower trust.

Not enough detail. Show your template

A failure would usually come with other signs, e.g. smart errors, a disk being disabled which would come instantly. Array status is essentially a "summary".

10% in 1 year means you'd still have 9 years left at current usage... Assuming that's what we're seeing, 2.4TBW in a year is nothing.

Check the db container required in the official compose file GitHubimmich/docker/docker-compose.yml at v3.0.3 · immich-app/i...High performance self-hosted photo and video management solution. - immich-app/immich

Fix your VPN config, can't reach the webui until VPN is connected.

Might not be related at all. What's the current destination of the copy? I see you have a 16TB drive and a small 4TB, if something is currently being transferred to the latter it'd be way slower than the 16TB. But a failing drive in general can have highly varying speeds. Regions that do not fault completely might take more effort to read/recover.

Not that I know of, but I've never tested for how things scale with the number of drives/storage locations. I'd expect "fuse/not fuse" has more impact that "fuse with few drives/fuse with more drives".

If they're on exclusive shares no overhead, otherwise there's some regardless of location. If the share is not exclusive fuse always has to look on all drives (both from array and all pools) for where the file actually is/has to be created following the allocation rules.

Not unless you "hack" things a bit, on zfs different shares are separate datasets, so from ZFS' perspective they're entirely separate and moving data between them means rewriting everything. Depends what you're writing, for large files probably not, for small ones definitely. The overhead is mostly on file open. If FUSE is an issue then make only the exclusive share, don't use the stock mover but write your own script to offload to array instead of moving to another share and then use unraid's mover.

You can't just change the drive assigned to the pool, click on the pool name, delete it entirely, then create it again with the new disk. If once that's done and the array is started it asks to format then come back.

Sounds like you're assigning it at the wrong place since that would only show for a drive that's in the array, not in a pool.

That's why selfhsoters is winding down. Why did you even try to submit to a third party repo? Make your own and take responsibility for your app instead of trying to conveniently make it someone else's problem. "Conventional" development provides some implicit trust, if you don't understand what you're doing at least some you're not getting your app working in the first place. With AI-backed development that's all out the window, anyone can get something that "works" but without the author being necessarily capable of reviewing the output, and that has led to countless scandals about serious issues/vulnerabilities in new apps. So with AI-assisted development trust goes out the window too regardless of how much experience you have since your experience probably doesn't encompass everything a full stack app involves these days. You might have 30 years experience in backend dev, but the frontend the AI generated for you can have massive issues you wouldn't recognise even if you "review" it because that's not your field and you essentially have 0 years of experience on that particular subject, and they'll go through. Also don't use AI to respond...

You can add a PMA_HOST env var with the server ip.

Is your VM set up for UEFI boot?

Downgraded, this looks like it was unnecessarily rushed way too early. Maybe should have been gated to next unraid beta.

That was fixed yesterday, update/reboot

Data Volume monitor spams logs so maybe remove it during troubleshooting. Nothing striking outside of all of Unraid, plugins and apps being woefully out of date included some deprecated ones, so probably gonna need to work on that first.

From posts there seems to be something related to icons not loading if they're not served from https, so people who used local files as icons just get stuck until a timeout?

The repo has changed to automaticrippingmachine/automatic-ripping-machine 1337server/automatic-ripping-machine is still there but not getting new pushes. @W3LFARe can you update the template?

I'm not aware of syncthing being able to use anything other than sqlite? Anyway I've been using the binhex container for 4 years and never had a single corruption event. There must be something wrong with your system. https://docs.syncthing.net/users/faq.html#my-syncthing-database-is-corrupt

If you make a properly formatted post with a title that makes it obvious it is a support thread for a plugin mods will recognise and move it as necessary. This is unreadable though.

See the last few posts, searxng has recently changed stuff that requires adapting your config files.

ZFS doesn't "need" the RAM, it just uses it if some is available and frees it when something else needs it.

You never refer to a bridged container's ip, as you see they're disposable and change. You refer to the server's IP. On br0 you can't select ports since the container always has all of them on that ip, but bridged containers can't reach it unless "host access to custom networks" is enabled, that's also a solution but the former would usually be preferred.