TyantA

It felt like a hardware issue out of nowhere. I haven't had time to go tearing into the system, but I did put a fan on it, and it stabilized. It hasn't rebooted since, to my knowledge. We had a wood fire on that night and it was (by all accounts) unreasonably hot in the basement where the server is. I'm going to chalk it up to heat. But since moving to my old desktop's Ryzen X570 Taichi setup, I've lost the ability to monitor temps and haven't had the time to figure out why.

Plex had been in use. Audio got more and more stuttery then the system went down. Photos were being accessed at the same time, so slightly higher workload than idle? In the syslog I see "Fix Common Problems: Error: Machine Check Events detected on your server Nov 7 20:33:34 Slipstream root: mcelog: ERROR: AMD Processor family 23: mcelog does not support this processor. Please use the edac_mce_amd module instead. Nov 7 20:33:34 Slipstream root: CPU is unsupported" But... this has been running this hardware (Ryzen 3900X) for months without issue. I see mention of a share reference which has since been rectified. Still rebooting. Ideas? diagnostics-20251107-2033.zip

I understand, but in my haste to troubleshoot I rebooted before grabbing diagnostics so I was under the impression it would be less helpful. If that is not the case, please see attached. diagnostics-20250323-1536.zip

Looking to replace SSDs. Shut down dockers, VMs. Shut down respective services. Set shares cache > array Invoked mover All but /system folder was moved. Share for /system showed both array and cache under "locations". I used the terminal to move the files off the cache drive(s) Now all shares are showing green (parity protected). Great, they're all on the array... Except, no VMs or dockers show up. What did I miss?

Weird. Two of my 4 custom container (host) paths set up in Krusader got changed to the same (incorrect) path. Due to an update? Something more nefarious? How would I know?

It's time to make some serious changes to my unraid box and I'd love some input on how best to proceed. My goals are (in no order): Removing 3 existing cache SSD, replacing with 2x NVMe, & different (not necessarily larger) SSD(s). Cache is currently using btrfs. Move to ZFS? Currently single cache drives; may explore a mirrored setup. Swapping out an LGA2011 system for some AM4 hardware. Upgrading a bunch of array disks - DONE. Revisit if XFS is still the best fit for array drives. While not running ECC ram, want to set up local network backups for success (i.e. mirrored cache pool used during backups). My immediate question is: I need to extract the 1TB SSD housing 2x VM vdisks for use in another system. Currently it only houses the "domains" folder. Nothing special about these VMs. On the fence whether I want to back them up or start from scratch. If the latter, do I just "Remove VM & Disks", unassign the SSD and that's that? OR could I easily/temporarily migrate the domains folder to a different cache SSD? This would be ideal as I need that SSD out before I'm ready to do the full hardware migration. Setup: Current SSD cache drives are single drives running btrfs. Fastest for appdata & system, second... looks empty lol. Third with the domains dir for VM vdisks. Server is on 6.12.14. I do NOT have an amazing backup plan in place yet. Once the above is done, I'm spinning up another server with the LGA2011 hardware as part of a better ongoing backup strategy (including a third off-site server, cloud, etc.).

This happened to every share except my appdata, domains, isos and system (the ones where the shares' mover action is set from secondary to primary storage.) Did @dojesus' suggestion of copying the free space value so a very many shares and that seems to resolve it.

This Sans Digital Mobilestor MS4UM+(B) is a rather old unit that acts as a tower of hot-swappable e-sata port multiplier for 4 drives in JBOD mode with option for USB 3.0 connection. I recently got one NIB. My P9X79 Pro has e-Sata 6GB/s that I've never used. Is there any reason to think that this wouldn't work with Unraid as an unassigned device? (Potential chip/controller incompatibility, etc.?) I'm rural but I have family in town with a significantly faster broadband connection. I'm thinking of dropping an Unraid box at their place and using this device as means of shuttling data back and forth. Good idea?

Update: Took a bit more time and tested: From within both VMs, I could NOT ping my router or the unraid web UI. That led me down the path to realizing both VMs were assigned an IP (DHCP) on the wrong subnet. I just haven't figured out why... and why that happened out of the blue, seemingly after Windows updates. I'm trying to determine if that's an unraid core setting issue - don't think so Network Settings shows the correct subnet for its IPv4 address, gateway and DNS server. In Windows itself - why would it, when set to use DHCP, not pick up the correct subnet? A VM config issue. It's just set to use br0 which, under network settings shows the correct subnet under "route". So... it must be the 2nd then. I guess I'll manually assign an IP and see what happens... Edit: Manually assigning an IP on the correct subnet (obviously) worked on the new VM I spun up. I still have no idea why it changed (guessing windows updates) moreover why it's not automatically picking up an IP from the correct subnet.

Yes, I can. I assumed the same, so I just spent the last hour spinning up another VM and it too cannot access Unraid's shares...

Thanks for the reply & idea. Just checked - Network Source: br0 is what it's set to. Edit: the only change I made - and this was AFTER the issue arose - was Fix Common Problems had warned me to change the docker network type to ipvlan, so that seems completely unrelated.

Win 10 Latest Unraid Can access internet This VM has been fine for ages. I had to log in, so I presume it rebooted due to updates. Windows did give the slide-out notification of a "Network 2" connection, oddly. I told it I was on a private network. It's been a while since I've had to troubleshoot an error like this but I spent an hour and a half on it and got nowhere. (Enabled sharing devices on local network, set to private network, found & uninstalled the most recent Windows updates...) Any one run into the same thing & fix it? TIA>

That seems to be what I'm observing. I forgot to mention that the error happened as my monthly parity check began, resulting on 2048 error before it aborted and got the red X label.

I find this confusing. Sadly, I don't believe I captured the syslog before shutting the server down. One of my disks scared me with a red X. I ordered new drives, pre-cleared them and started the server up, replacing the one drive. Rebuild went fine. (Which means the controller doesn't have an issue as it's on the same port). Then I took the "red x" drive and put it in my 2nd server. So far, no SMART Errors presented so I ran a quick self test and it says there are no errors. Now I'm running the extended test. My second server isn't vital; what would you do prior to deploying it again - if at all?

I have one unraid box with a 1050Ti in the primary PCI-E slot and a 1660Ti in the secondary. I'm bringing up another system to split out my work and personal needs; thinking of moving the 1050Ti to it (as secondary) and reverting to either my passively cooled GT730 or FX570 as primary GPU in the main/personal rig. I guess I'm giving up NVDEC with support for h.265 which was the reason for this combo to begin with, hrmm. I do have some h.265 content but as I'm limited to 1080p; not much. Maybe I should leave the main server as-is and just accept that the work system is only for work. (The thought had been light gaming one day using separate systems instead of multiple VMs on the main rig). Any input appreciated.

That turl. So because it's a bz file, you're saying they can't (at least easily) be changed outside of an update. So the "low hanging fruit" risk is attack surfaces on dockers and VMs and their inherent potential security issues (ex, Windows), but they are in theory completely isolated from the host OS... and there's nothing really there (Unraid level) that would persist beyond a reboot. So if one were truly concerned, you could blow out / restore a VM from a known clean state and be sure dockers are up to date and follow security best practices.

If it's a website, I'd look for rogue code. If it's Windows I'd just format the system (lol). Unraid? I have no reason to believe mine has been, but I'm still curious - what would one do? I suppose you could start from scratch but would there be an easier way (maintain drive config at least)? Would just copying over fresh Unraid files to flash suffice? Could a compromised VM pose any issues to the rest of the system/network? In theory I'd think not but...

linux 4096 bytes windows 260 characters unless you do some fancy work to disable that limitation but bytes != chars So that still doesn't answer the question. Inquiring minds also want to know if browsing unraid from a windows based machine will run into issues manipulating files in paths beyond 260 characters. And if Krusader is "smart" enough to alert me if files being moved to a longer path will run into issues.

Hello, I'm in the process of reorganizing my data. Due to my multi-level + descriptive directory naming conventions, in Windows I often bump up against "this path is too long" type error. 1) Does unraid/linux have the same path length restrictions as Windows? 2) If I end up moving a directory (and its subdirectories) to a nested folder where the resulting path would be too long, will Krusader notify me of this? I'm (obviously) trying to avoid lost data in the process. TIA

I have a particular disk, it seems. It was pulled from a Windows laptop with the intent of using it as a 3rd cache drive just for file transfers. I installed it, it showed as unmountable as expected with no option to format. (I know where to look). I thought OK, I'll blow away the partitions so I used power shell to delete all the partitions on the drive, then I created a new volume. (There were 7 in total (Dell rig, all sorts of recovery partitions etc.) Left it as raw. I got the dreaded "unmountable -Unsupported partition layout" but there was no option to format the disk. Fine, I brought it back to my PC and formatted it there as an ntfs drive. Dropped it in unraid and this time, the format button showed up, except it didn't work. I tick the "yes I want to do this", format, it says "formatting" then it reverts to "Unmountable disk present and the option to format again. Loop. On the right, it says "Unmountable: No file system". Ideas? Never had this much issue taking a drive and dropping it into unraid. More curiously: I unassigned it from the cache pool and now under unassigned devices, it shows as mounted. [SOLVED] That was my clue. I guess in looking at the disk, I had mounted it as an unassigned device, then, without unmounting it, I assigned it to a pool. Then I couldn't format it. When I unassigned it, unmounted it then assigned it, I was able to format it!

Yes, I have backups of both drive, original apps and trial appdata folders. Ok so what I'm hearing is, because my trial used all default locations vs. the custom ones I had set up, my fresh install is "seeing" the docker.img file which I should obliterate and restart, since my objective is to have a clean start. Cool, I'll try that. What started confusing me was thinking about the fact that the trial put an appdata folder on cache and the array, so the new install would also be pointing to those files, but the current unraid install isn't aware of those installs, so I was planning to obliterate them as well. BUT, one of those has my most recent Plex cache/metadata so I have to be careful. Maybe I should just rename the "old" appdata and move on. Edit: That worked. I nixed the docker image and was able to start fresh. Thanks!

I had an old version of unraid running on my "production" rig. This used a custom /apps folder instead of appdata. I tested moving my plex metadata to a fresh install with a trial USB key. It worked. This created a mnt/user/appdata folder I then backed up and wiped my "production" key as I wanted to start from scratch. This included a brand new cache drive as well. After enabling docker, I saw the two dockers I had set up with the trial key were there, less their icons. I tried removing Krusader. It's gone from the Docker tab but some (icon?) files persiste in /appdata and for whatever reason, installing it again just goes through the motions but it doesn't actually install. The other docker was plex. I'm being careful with that one as it is where my Plex meta/cache data was. I guess I'm just a bit confused as to why those are showing up, having not installed any dockers on this fresh key install. Obviously they live on the array and were (likely) set to "prefer" the old cache drive. I guess as long as it is (also?) on the array, it'll show up in the docker tab too?

One more question. I'm trying to do the following. Would you suggest a particular order of operations other than this? Move Plex linuxserver > binhex while maintaining library/watch data. Install nvidia GPUs I've had on hand forever (1050 Ti, 1660 Ti) FINALLY Upgrade Unraid 6.5.3 > current w/ nvidia support Enable Plex hardware transcoding Replace cache drive showing signs of age Replace 3 older drives with new, larger drives

Thanks squid for the prompt reply. I kind of assumed as much (based on SI's deletion in one case) but being the reverse situation, I wanted to be sure. Thanks again.

I watched SpaceInvader's video covering this topic however his media was already set up to use /media. I'm moving from Linuxserver's container to binhex (possibly plexpass) and need help/clarification for the opposite scenario. My libraries within plex are /tv, /movies, etc. and my mappings are /mnt/user/tv but in the binhex template, it's looking at where to map /media. As you can see, I don't use /media for anything so... how do I handle this move? TIA