Kilrah

Looks like it does get stopped. Any other containers that are set to be skipped that might access the same paths?

Log you posted doesn't show it being stopped.

I have the plugin set to archive the syslogs (and keep 10), that works but I noticed that now Unraid rotates the syslogs after about 1MB (syslog.1,...) and those are lost, the plugin does not merge them when archiving, it only keeps the main syslog file. That's valid for the now built-in "syslog-previous" the OS makes. When using the plugin it also saves diagnostics so the full log is in there but it would still be good to merge any .1, .2 etc when saving both for the plugin and system.

Use the NUT plugin instead of the built-in UPS handling

The ._ files aren't duplicates, they're junk metadata sidecar files created by macOS. Shouldn't affect anything.

The plugin will just adjust the floor from now on for new files. if you had your min free space too low in the past and your cache is already overfilled it won't do anything about that. It's a preventative measure, not a fix for when things are already wrong.

That script seems to only back up the user scripts, you always want a backup of the full flash drive anyway. The Appdata Backup plugin most people use since you typically want your services' data backed up can do that for you.

Whatever tunnels or reverse-proxies the unraid UI must support websockets and have that enabled. The Unraid WebUI must also never be publicly accessible.

It's again an interaction with exclusive shares. When you select a path in /mnt/user with the picker and tick the checkbox it fills in a /mnt/cache path. Don't know whether that's an unraid thing or a plugin thing, but as it is it'll be a recurrent issue.

The pool folder is for pools as its name says, array config is in the super.dat.

Convert those vmdks to raw, transfer them to unraid, create a VM and assign them. I'd try either Windows XP or generic Linux seeing that list.

Not directly but you can create a script and paste the contents of that in.

disk5 doesn't mount because its emulated filesystem is now corrupted, probably from the impatience and forced shutdown. It did mount properly in the previous diags between the start and stop. https://docs.unraid.net/unraid-os/manual/storage-management/#checking-a-file-system

And that's not normal. The last diags were taken with the array stopped so can't see what could have caused it. As you know there is no TRIM in the array, that can severely impact performance. You're also not typically doing full drive writes in one go outside of the array. The Chinese no-name isn't the focus, terrible performance on long sequential writes happen on name brands too, some Crucial SSDs are known to be absolutely awful for that.

Then it sounds like the paths you gave to krusader are incorrect.

Linux caches things, you might have paused but there are still probably GBs in cache to flush and that'll take a while if the drive is that slow, need to wait for that to be finished. It should be available as /mnt/disk5. But yeah it just seems like the typical low end SSD, when the SLC cache is full they can slow down to single digit MB/s.

Yeah but there's no reason to put it in the excluded list since it's properly recognised as external and backup exetnal volumes is set to No.

Should use the support thread for the plugin, probably

Should be fixed

Just use the plugin now.

Yup, new push is fine

bitmagnet updated fine here but it looks like postgres was switched from 16 to 17, that won't work on existing installs, can't upgrade postgres major versions. 2025-03-02 19:46:00.453 CET [69] FATAL: database files are incompatible with server 2025-03-02 19:46:00.453 CET [69] DETAIL: The data directory was initialized by PostgreSQL version 16, which is not compatible with this version 17.2.

Check that /mnt/user/appdata is in the appdata sources setting of the plugin.

Correct, if there's no primary/secondary nothing will be moved.

and it says you're out of space, so check that or provide diagnostics.