mathomas3

the issue started within the past week

cant find a clear error... but due to some unknown issues... the docker takes a long time to load and when it does I cant find it in the app... anyone else?

The array is hosted on unraid. Zima is trying to access it via SMB. UNRaid is doing it's thing... always there and protected... it's zima that dropped the connection after 7 days and after I rebooted it, it forgot about the share(I have posted this question to them as well) I am not getting much from them... So that leaves unraid as a valid option, but I have not heard/seen a way for unraid to access a smb share and have it accessable to a docker... Thoughts?

someone?

Hello all, I have found myself in an odd spot and use case and I started wondering if UNRaid does this. I have been here for many years and my unraid box is cluttered with dockers and have grown weary of a single docker running away screwing with everything else. Thus I have started exploring offloading some of these dockers to other hardware. Problem is that they would still need access to the UNRaid SMB shares. Currently I installed ZimaOS on a trial basis and after 7 days, the SMB share went dark and after a reboot the share was completely gone. Which got me thinking. Could UNRaid do that? It's not something that I have considered before but I suspect that it can. Just havent seen it mentioned or asked before. Thoughts?

I took one of the 'failed' drives and connected it directly to a laptop and it was found, needed to reformate the disk to be accessed, but it woked fine...

Someone... Anyone?

I went ahead and ordered up some 22tb SAS drives. It would be nice to know if these disks are SOL or...

I tried moving around the HDDs to different slots and they are still missing. For the life of me I cant logically figure this one out. Loss power. Bring it back online with one missing disk. I replace it and then the other parity drive goes missing. My entire array is SAS disks and these newer HDDs are sata. Perhaps that's why? But why would they work one day and then the next go dark...

I hear you... but with a 24 bay enclosure either everything works or nothing does... per my expirance, but for the typical user here... that's sound advise

If I recall correctly... I had to play with the position of the hdds to make everything work/talk... I tried moving some things around and still the old parity drive isnt found... in this posted diag, the new disk isnt attached and the old/'working' parity drive is in a new drive bay... still not found... advise?!? tower-diagnostics-20251028-2030.zip

Logs are attached Though they are off of a fresh reboot and some details from the lost disk are not included tower-diagnostics-20251027-1816.zip

Hello all, I have a strange one that I am trying to wrap my head around. Earlier yesterday, the system lost power and thus triggered a parity check. Everything was seemingly running correctly but after a few hours one of my newest to me(renewed) 24tb sata drives was missing after posting around 1000 errors. Thinking that this might just be a bad disk, I replaced it. Odd thing is now the second parity drive is missing. I did reseat the HDD while trying to locate the one failed drive, but it's there. I tried reseating and swapping both of the parity drives and still it fails to show up. Just for grins I did test the 'failed' HDD on a secondary system and it seems to be fine. I was able to format it and write some test files to it. I know logs will be requested but I did power off the sysstem as it's entirely unprotected at the moment. Any rough clues or ideas? the specific drives in question are MDD sata 24tb. MDD23tsata51272e

Hello, I just got in a pair of Tesla M40s that I would like to use for LLM. I plan on putting that into the server but am a little bit concerned about loading it up as a docker setup. How would I limit the llm to those GPUs, are the llm and Plex going to fight for those resources? Given that, would it be best to load it up into a VM and do hardware passthrough? Haven't done that in unraid as of yet, is that a thing? Thanks

hmmm... now TA has moved to hdd 8... 7 is under the 100gb window... so... it's kinda doing what it should but ignoring the cache disk? huh?

Just adding notes to this as it seems to be a bug of sorts... disk 4 is holding steady with 69gb of free space... disk 5 has 103gb of free space... disk 6 has 20gb... disk 7 is currently being written to... and has 100gb of free space... why these files are bypassing the cache drive??? seeingly there is some logic happening, via docker restarts/reboots... today I moved unraid to a complete new system from the old R340 so yea... perhaps involving the TubeArchivest group is warrented at this moment

The container is writting new data af far as I know... Ill look at it closer

As far as I know... you have to set SOME split level of sorts... The verbage of this setting leaves you wondering why disk 4 is special...

Could this explain/fix the issue? " Disk Space Management strike Install Support Forum Pin App This plugin was created mainly for those who use the split-level feature in Unraid. Due to how split level works, it will ignore the minimum free space setting and continue to move stuff to disks that are full/almost full. This is because split level tries to keep files and folders that belong together based on your split level setting on the same disk, and split level trumps all other settings. Even if there's little space left on the disk. So to combat this, this plugin will automatically move Movies and TV shows from disks that are below the threshold setting to the disk with the most free space available. It prioritizes to move movies first, then if no movies are found it will go to TV shows and move the shows with the fewest seasons first. "

Have you tried accessing the GUI via a different system or via incognito mode? sounds like a cookie/cache issue

Just to note, I tested NZB360 and behaved as it should, accessing the cache before any of the disks. TubeArchivest on the other hand is the one that is bypassing the share rules. Just spit balling here... If I have a share at /mnt/user/Media and I have a docker that accesses a file at /mnt/user/Media/YT/HiThere/. That docker should follow the rules set for the share at /mnt/user/Media... Correct? If that's not the case, it would explain what is happening Thoughts?

Hello all, This one is a bit confusing, I have been here for a long time been a user and for the life of me I cant explain why a docker is writing directly to a single disk and ignoring share settings. For the primary share I have it setup to Fill up 101gb free Cache > Array Yet most recently my disk 4 was left with 24kb free while I have a good number of disks with 100s GB free and a couple with 7tb free. I have double checked the shares, the disks, parmissions. On a whim I did update the OS to see if that corrected this issue. Nope. Im at a lose. tower-diagnostics-20250726-0017.zip

to note... my best guess is that this disk was shoved into a SATA interface(Its SAS) and thus pushed up the 4? pins right above the key(for a sata connection) and thus severed one of these pins? Not much to be found on the internet about this but, yea... trying to help get a clue as to what the issue is... Does someone here know if those 4 connectors atop a SAS interface could be used/is to lockout write operations on a SAS drive?

The interface damage appears like the disk was dropped into a sata caddie and yea... not good... out of the 5 disks I got... 2 have lifted pads... this third disk is the only other disk I am willing to put into my array...

Never seen this before on a HDD... but the logs confirm that this disk(which has some interface damage) is currently write protected... Ideas? Jun 11 21:31:39 Tower kernel: scsi 2:0:26:0: enclosure logical id (0x50050cc102058f07), slot(1) Jun 11 21:31:39 Tower kernel: scsi 2:0:26:0: qdepth(254), tagged(1), scsi_level(8), cmd_que(1) Jun 11 21:31:39 Tower kernel: scsi 2:0:26:0: Power-on or device reset occurred Jun 11 21:31:39 Tower kernel: sd 2:0:26:0: Attached scsi generic sg25 type 0 Jun 11 21:31:39 Tower kernel: end_device-2:0:26: add: handle(0x0023), sas_addr(0x5000c500d8ae8fe5) Jun 11 21:31:39 Tower kernel: sd 2:0:26:0: [sdy] Spinning up disk... Jun 11 21:32:16 Tower kernel: .................................ready Jun 11 21:32:16 Tower kernel: sd 2:0:26:0: [sdy] 35156656128 512-byte logical blocks: (18.0 TB/16.4 TiB) Jun 11 21:32:16 Tower kernel: sd 2:0:26:0: [sdy] 4096-byte physical blocks Jun 11 21:32:16 Tower kernel: sd 2:0:26:0: [sdy] Write Protect is on Jun 11 21:32:16 Tower kernel: sd 2:0:26:0: [sdy] Mode Sense: df 00 90 08 Jun 11 21:32:16 Tower kernel: sd 2:0:26:0: [sdy] Write cache: disabled, read cache: enabled, supports DPO and FUA Jun 11 21:32:16 Tower kernel: sd 2:0:26:0: [sdy] Preferred minimum I/O size 4096 bytes Jun 11 21:32:16 Tower kernel: sd 2:0:26:0: [sdy] Attached SCSI disk Jun 11 21:32:17 Tower emhttpd: online: ST18000NM004J_ZR57HZKZ0000C2232NF7_35000c500d8ae8fe7 (sdy) 512 35156656128 Jun 11 21:32:17 Tower emhttpd: read SMART /dev/sdy