kramttocs

Hey @AndyLively Is yours still stable? What pcie board did you go with?

The fun never seems to end. Really like unraid and my setup but haven't hit stable yet. A lot of unnecessary detail in this post but wanted to detail it for my own sake if nothing else. Have been running with the 32gb, my windows vm (dedicated nvme on motherboard directly), and a smaller set of docker containers that I need but keeping memory under 80%. Two days ago everything became unresponsive to the point of having to hard reset. No indication why. Parity finished after 36 hours and was back to functional. I setup a remote syslog server since apparently the bad stick of Ram isn't the only problem. This morning I get an alert that one of my Core drives has errors. Core is my (4) 4tb sn850x mirrored pool that is on the pciex4 card (non-bifurcation) and doesn't have a secondary location. Sure enough one of the drives was at 10k and then quickly to over 24k errors. Grabbed a diagnostics real quick and shut it down. Started it back up, started the array (cancelled parity) and watched the count to make sure it didn't change for a few minutes. Applied the boot parameters are mentioned in the error logs (will speak to this later). VM service wouldn't start so disabled it and docker and shutdown. Removed the 4xNVME card and rotated all 4 nvmes to check if a slot or drive problem. Booted. VM service started this time and my vm started. Docker service still wouldn't. Figured now was as good a time as any to switch to directory vs image for Docker so did that, restarted and this time my usb drive wasn't recognized by the bios. Removed it from the internal header adapter and stuck it in a rear port. Bios found it this time and all booted fine. Docker and VM running now (same subset of containers as before). Watched the error count a bit longer and no changes. Ran a scrub which had no uncorrectable. Ran another with no errors reported. I haven't cleared the errors yet though probably should. The boot params I have now are (OS and GUI): I already had the pcie_aspm=off there from the first read-only issue. label Unraid OS menu default kernel /bzimage append initrd=/bzroot nvme_core.default_ps_max_latency_us=0 pcie_aspm=off pcie_port_pm=offThese came from my syslog server at the start of it all. Nothing before this : Not very familiar besides some googling today on these params but sounding like maybe pcie_aspm=off wasn't enough to keep it alive and happy. Looked at the card again while I had it out and there doesn't look to be a way to add external power or would try something like that. The temps on these are never high - 30-40C and just get up to the 60s during the scrub. The nvme's aren't heavily utilized either. Usually single digit MB/s or lower. If they were getting a lot of IOs I probably wouldn't even consider this card approach. Similar to https://forums.unraid.net/topic/189754-cache-drive-stops-working-nvme-controller-crash/. Hopefully not just a bad hardware combo.

Finally got around to memtest. First test with all four showed 2 errors quickly. Testing each stick one by one showed one failing with an error and all others passing. Running multiple passes on two sticks to run with for now and will do the same once I get a replacement and put the four back in. So fingers crossed the nvme board has no issues at all. Edit: 5 passes with the two sticks (I'll confess I turned xmp back on first for these passes) and no errors. Server is back up and running with the 32gb for now.

Appreciate it!

Are there still current issues with drivetemp? On 7.2.6 but the potential instability warning gives me pause.

Yep, I don't disagree. Appreciate JorgeB for pointing it out as my searching was focused on the other errors and didn't make a connection to ram. Fingers crossed that's it. Edit for random rambling: I will say that the Sabrent card works pretty slick besides this (which hopefully isn't even attributed to it). My mobo doesn't support bifurcation for 4 drives so this was the best option I found outside of losing my gpu and going with a x8 card in the top slot. I don't game much so dropping the gpu to the (s)lower slot would be fine except it hits my psu. That means I'd need to buy a low profile/single slot gpu and haven't found a great option there.

Will do. Reminds me I also need to check the bios for some goofy Asus AI overclock setting that seems to default to On when I make bios changes (which I did to change some pcie settings when going to unraid). While maybe not related to this issue, it's caused me grief in the past.

Since I'll want to run memtest for awhile overnight, any benefit to doing the scrub now before? Or best to do it after the memtest? I could quickly also just turn xmp off as a first action before doing either the memtest or scrub. Just picked the scrub bit up from here since you gave me something new to search on: https://forums.unraid.net/topic/165719-cache-btrfs-write-time-tree-block-corruption/

Thanks @JorgeB . That was fast. Been using this mobo, ram,cpu combo for a Windows machine for several years now and didn't really change much in the bios when going to unraid so didn't think to mess with the xmp settings. Will give memtest a go. Edit: The ram is rated at 3600, which is what it's at so I think years ago I turned on XMP 1 in order to get it up there instead of 2400.

I have a SABRENT 4-Drive NVMe M.2 SSD to PCIe 3.0 x4 Adapter Card [EC-P3X4] in a lower slot (top is gpu) that has four 4tb WD SN850x's. They are btrfs mirrored and treated as my fast storage that doesn't go to the array. Things have been working pretty smoothly but the drives went into RO mode last night, causing (I think) a docker container to go haywire triggering an oom situation. Showing two btrfs corruptions now. Sabrent support isn't able to give me anything as they only support the unit on mac/windows which is fair - it's documented that way. I captured the diags (out of unnecessary caution I had it redacted a bit more so if there is stuff missing that is needed to help me, let me know), turned Docker and VMs to Disabled, set "pcie_aspm=off" per google searching and did a shutdown from the terminal. It wouldn't cleanly stop the array due to the Docker service misbehaving I believe. While shut down I reseated all of the nvme's and the pcie card. Started it all back up but would like to see if I/we can figure out why this happened. Temps all looked good and haven't seen any SMART issues. Running extended tests on them one at a time now. Been running this (AI provided) to keep an eye on changes: grep -Ei "AER|PCIe Bus Error|RxErr|BTRFS|I/O error|read-only|corrupt|forced readonly" /var/log/syslog And looking to see if the corruption count changes: diagnostics-20260507-2125-redacted.zip

Glad this thread exists. This really does need fixed in the UI. As of 7.2.5 for groups you DO need to add the minus sign in the chatid file.

Thanks! I am not really clear on when it would work vs when it wouldn't in the real world to be honest. Just saw it as I was reading the doc. 🙂

Haven't been using Unraid long so still wrapping my head around some of the stuff. Noticed an odd situation earlier today and since I recently enabled Exclusive Access, want to have an idea of what might happen if it shows up again. 4 device array (xfs) 1 device ssd Cache pool (btrfs as I will be adding another soon). 4 device nvme Core pool (btrfs) Array uses the Cache pool as primary Cache pool has some exclusive shares (logs, transcodes, downloads etc) Core is all exclusive shares (appdata, system, domains, etc) data_core is a share on Core. I moved some stuff last night from cache > downloads via a RootShare on my Windows machine (VM in unraid). I noticed this morning that data_core showed up on the Cache pool with those files I had moved. No idea why. I moved them and deleted the folder from the Cache pool. So all that preamble to ask: what happens if that occurs again now that Exclusive Access is on for data_core? Would it automatically turn off or would those files in the wrong place just be "missing"? ... My only idea on why this might be happening is that early on I renamed the share from data_fast to data_core. It always had secondary=none though and if that was the cause I would expect to see 'data_fast' show up out of place somewhere.

I have a dedicated drive that is permanently mounted in a Windows VM via a 'Manual' disk/passthrough. It's a storage disk (WD Purple for Blue Iris). I need to share it with a docker container (tdarr). What's the best way to approach this? I haven't experimented but my understanding is that if I tried to mount the passthrough disk via unassigned devices it would causes issues with the vm. I could create a share in the Windows VM and mount that share in unraid but wonder if there is a better option. Just seems like a few moving parts there

Thanks for the clarification - different issues that we are running into. Yeah, aware of the lack of native docker-compose and am using Dockhand to manage that. My issue is likely around permissions but wanted to check before starting fresh.

It's early AM here so I am not positive we are hitting the same issue but are you able to get OpenCloud working on Unraid and this is just the app in a vm that isn't working? Trying to migrate OpenCloud from a nas (docker compose) to Unraid (docker compose) and it isn't having it. So before I start from scratch and migrate data, wanted to see if there was some bigger issue that made OpenCloud+Unraid a no go.

Thanks for this. Been using Dockhand for awhile but not on unraid and only to manage external compose files. Since moving to unraid, going to handle it all in Dockhand as I migrate. It does look like Dockhand can correctly resolve the host data dir but per recommendations should the template contain these as defaults? Matching internal and external volumes with DATA_DIR defined. I know /app/data is the default in Dockhand but seems like that may be legacy? https://dockhand.pro/manual/#volume-path-mapping

https://docs.unraid.net/unraid-os/using-unraid-to/create-virtual-machines/vm-conversion-and-migration/#migrating-a-physical-disk-to-a-vm I would have expected the sysprep part to be under these two options: The larger heading of Convert a physical disk to a VM > Windows where it lets Unraid do the conversion. Since we are talking about it, it seems like it should explain a bit more of target, source, and at what point Unraid actual does the conversion. But since we are making an image that could be spun up multiple times, sysprep would makes sense here The INFO box under the Migrating section for this part:' Disk image conversion: This converts the physical disk to a virtual disk image (.img) for use in the VM. ' a. Having this INFO down here is a little confusing since we already went past the physical disk to a vm section. b. So I say sysprep makes sense for this but it's really the same as #1. I think? Edit: this still may be a difference in the Windows install being on the same hardware as unraid will be. So the doc may just not have been written with that scenario in mind.

Thanks! I've watched that one a couple times (no doubt will a couple more) and is pretty much spot on for what I want to do. Due to the age and the official doc mentioning the sysprep while the video doesn't, that made me hesitate. I'll use the video and skip over that part in the doc 🙂 I also need to watch this one a couple more times as it has some good stuff: https://www.youtube.com/watch?v=QaB9HhpbDAI

Making preparations to setup unraid and do some consolidation. I have a Windows 11 install I use as my primary pc but want to do so within unraid. Getting familiar with most of it after reading and watching but not clear on the need for sysprep/acronis in this scenario. I only see that mentioned in the doc and no where else I've found. I want to create a vm and point it to my existing disk. The dedicated NVME is just the Windows install/recovery/etc and it is currently the only OS on the same machine that I am going to use unraid on. If I don't plan on making it into a vm image and want to retain the ability to dual boot to it if needed, do I have to run sysprep? It may be that the part I am getting hung up on is that my windows install is using the same hardware so it's not really "moving" Was hoping I could create the VM, edit the xml like this: <disk type='block' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source dev='/dev/disk/by-id/[your-disk-id]'/> <target dev='hdd' bus='sata'/> </disk> pass another unassigned hdd disk I want dedicated, the gpu card, and spin it up. https://docs.unraid.net/unraid-os/using-unraid-to/create-virtual-machines/vm-conversion-and-migration/