Kilrah

Should be the full URL, usually the dockerhub page, for ghcr something like https://github.com/ccwod/meshtastic-signal-bridge/pkgs/container/meshtastic-signal-bridgeProbably not what blocks it but priviledged could have. Communication around this is known to not be great, but a better place to ask about it is probably in the Community Apps thread.

Did you fill in the form? You've set privileged=true, that's most likely unnecessarily dangerous for this purpose and would be rejected if there's no good reason. Registry field seems incorrect too.

It's AI BS that is spouted out with no understanding of the context. Plenty of us using them just fine. It's obsolete and not recommended "because it's commercially abandoned and we have PCIe5 storage now". You don't need a PCIe5 SSD to boot Unraid from. The almost unlimited endurance is a good thing though, which it doesn't know about.

You didn't read the 2nd paragraph of that it seems. What's not supported is the original purpose for those of being used a transparent cache for HDDs, but they still work like any other SSD for general storage.

0.2.3 is in beta stage. If you want to test it because you know why you need to change the tag yourself. If you don't know that you probably shouldn't.

You usually use a reverse proxy to redirect to your various services and that'll handle certs.

It's the lack of Docker container that seems more surprising to me.

An update for what? The plugin itself? You showed your autoupdate settings for containers but not for plugins.

Try another USB port, this one might be damaged/have dirt in it that creates a short.

Ah lspci is actually wrong too, and intel even have a page on it https://www.intel.com/content/www/us/en/support/articles/000094587/graphics.html

No, it was about intel_gpu_top, AFAIK lspci should be correct but you never said where you were getting the info until now.

Was recently discussed on Discord with the author of the GPU stats plugin.

Known reporting error by the driver.

You must be confused because it's how it's been for basically ever. Fragmentation happens when some files later get deleted and the gaps get filled by new ones that don't quite fit and have to be... well fragmented where there is space.

That makes no sense, if you wiped and copied again there would be no fragmentation then, so pointless to run defrags. Pretty much doesn't matter with the usual filesystems used in the array.

Correct.

That's not even a thing in Unraid. How high are you because you seem to only talk nonsense in the various threads you've posted in recently...

No.

Install Unassigned Devices Plus on unraid, enable destructive mode, clear all partitions, then format NTFS.

No because you can't have a data drive larger than parity. If the system is trusted I would remove the existing parity drive, install the 3 new drives (1 data and 2 parity if I understand well), let it build parity (yes it'll take 2-3 days depending on activity), then replace one of the 8TBs with the old 18TB parity.

No out of memory event there, so probably an application problem so you should post in that app's support thread. You do have a number of problems reported by Fix Common problems that you should address especially the corrupted filesystem though.

RAM-mapped paths don't count towards container RAM usage, so if the container got killed because it used more than 16G then it means it needs more than that for what you're doing

You posted in a thread about NFS issues. Maybe create your own if unrelated.

It ran out of RAM, but dashboard shows filesystem, and increasing vdisk increases that, neither are related to running out of RAM. Logs are useless because of mover logging, disable that, reboot and post new diags after the next memory error. Do you have a memory limit configured on the container in question?

To mount an UD share the host has to be up at the time you click the mount button / it gets automounted at server/array start, but once it's mounted it stays so even if the host goes down and comes back up. If you try to start a container that accesses the remote mount while the remote is offline it'll fail, so don't start/restart containers that use them if offline. For the backup scenario in the first post better use something designed for it like urbackup.