uaktags

So I understand that we have "wait" and also can organize docker containers from top to bottom for auto-start priority, but is there a way we can add in dependencies? For instance, I don't want my Wordpress container to start until after I'm sure that my MariaDB container is running. Or for Sonarr/Radarr, I don't want them up and running until my download container is good.

Stupid me. But thjank you Jorge! I'll get to rebuilding

So my setup is with 8 Array Drives (4 connected to motherboard directly, 4 connected via a PCIE adapter) and then I have 2 nvme drives attached to a PCIe adapter. I had attempted to add a 3rd drive (which probably blew through my pcie lanes) and attempted to access it. Upon having a VM access the mounted nvme drive, the VM glitched out due to "pci" error that I did not capture, but I also lost one of my Array drives in the process. The drive became disabled and does not want to come back online. SMART appears clean for the drive to me and I was able to access the drive via another machine to ensure data was still intact and drive was operational. I'm currently running a Read-Check, but honestly not sure if that'll do anything (its an 18hour process, so if not, then i've wasted 18hours). Any help is appreciated. tower-diagnostics-20211206-1054.zip

Hey guys, So like a few others, i've been hit with a predicament caused by user-error. In a single move, I lost the contents of one of my shares (possibly during a mv command or a sym/hard link moment). While the files lost weren't "important" enough for me to keep a backup of, they were plentiful, and reacquiring would be a far more painful task than the idea of recovery. I saw from a few posts such as: https://forums.unraid.net/topic/92076-whats-the-current-way-to-recover-deleted-files/ https://forums.unraid.net/topic/80815-urgent-problem-how-to-undelete-a-folder/ https://forums.unraid.net/topic/73937-help-recover-deleted-files/ that a few others have fallen through the same user-error as me and didn't have a backup. The common replies were "maybe xfs_undelete" but more possibly "maybe UFS Explorer". For anyone that doesn't know, UFS Explorer is probably the worst company/product experience I have. The "standard" license for recovery is for a product called "UFS Explorer Standard Recovery" but i'd forgive you for accidentally getting their "UFS Professional Recovery" or getting confused with "Recovery Explorer Professional", or "Recovery Explorer Standard". These are all the same company, and for the most part appear to be the same software (just with limitations/abilities added or removed). If you make the mistake and get UFS Professional Recovery's trial, like i did, and start the painstaking 8-11hour scan for lost data.....don't worry, you can NOT use that saved scan on the Standard versions. So, if you mess up like me, you may buy the license for the Standard (~75$) but accidentally download the Recovery Explorer Pro or the UFS Pro Recovery, start a scan, and then realize you don't have the right license nor can you bring the results/scan over to the Standard. In the end though, Standard didn't work at all. It took about 3hours before it errors out and I haven't heard back from support. So I went with "xfs_undelete" instead. So, as mentioned in the other threads, you'll need Nerd Pack to download tcl and tcllib. Then what I did was I stopped my array and mounted some large external storage (truth be told, i mounted an old NAS i had with 4bays, that i had replaced with unraid). Then, after mounting my Destination drive, I basically downloaded xfs_undelete, and used the following parameters to fit my needs. I knew what I was looking for (for me, video files) and I knew a date range of when they were deleted (Jan 9th): xfs_undelete -t 2021-01-09 -r 'video/*' -o /mnt/remotes/nas-drive/xfs_undeleted/ /dev/sdd1 Now, the crappy part is doing it via cifs to the NAS, I can only run this for 1 drive at a time (the CIFS connection becomes unstable), but i reckon i could do this with drives connected via USB or SATA. The results though are awesome! Instead of doing a scan first of everything and waiting for the Virtual Filesystem to be created, and then doing a restore job [UFS Explorers method] this just scans inode by inode and recovers immediately. The filetype allows me to just say every file of this type, rather than waiting for the vFilesystem, so that's great, but it does mean i'm going to get a bunch of junk i don't want since i can't specify filesizes (oh well). Best off...its free, and appears to just work. Hope that helps others looking for similar support!

Nope, seems to have popped back up again. Strange.

Guess I'll just update that I haven't seen the error since posting.

Unraid 6.9.0 Beta30 Machinist x99 zx-du99d4 mobo (new mobo, old one was an ASMB-935...error started with only the new x99) dual 2643v3 64GB ram /var/log# grep -rn mce dmesg:257:[ 0.379352] mce: CPU0: Thermal monitoring enabled (TM1) dmesg:271:[ 0.380274] mce: [Hardware Error]: Machine check events logged dmesg:272:[ 0.380276] mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 20: c800a94000200e0f dmesg:273:[ 0.380278] mce: [Hardware Error]: TSC 0 MISC 800000 dmesg:274:[ 0.380280] mce: [Hardware Error]: PROCESSOR 0:306f2 TIME 1605623282 SOCKET 0 APIC 0 microcode 43 syslog:259:Nov 17 09:28:38 Tower kernel: mce: CPU0: Thermal monitoring enabled (TM1) syslog:273:Nov 17 09:28:38 Tower kernel: mce: [Hardware Error]: Machine check events logged syslog:274:Nov 17 09:28:38 Tower kernel: mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 20: c800a94000200e0f syslog:275:Nov 17 09:28:38 Tower kernel: mce: [Hardware Error]: TSC 0 MISC 800000 syslog:276:Nov 17 09:28:38 Tower kernel: mce: [Hardware Error]: PROCESSOR 0:306f2 TIME 1605623282 SOCKET 0 APIC 0 microcode 43 syslog:1887:Nov 17 09:29:36 Tower nerdpack: Installing mcelog-161 package... syslog:1889:Nov 17 09:29:36 Tower root: Installing mcelog-161 package... syslog:5144:Nov 17 09:41:14 Tower root: mcelog: warning: 8 bytes ignored in each record syslog:5145:Nov 17 09:41:14 Tower root: mcelog: consider an update Outside of this HWError, everything else is working as I'd expect it. Dockers are running, all cores are being utilized, nothing appears degraded in perf/usage. tower-diagnostics-20201117-1004.zip

Not sure if anyone else is experiencing it, but I'm having an issue where the theme engine doesn't seem to be sticking. I created the following issue with screenshots. Issue is present on 6.8.2. https://github.com/Skitals/unraid-theme-engine/issues/1

well I'm dense, literally the next paragraph had the explanation for the cache (brtfs) was to use scrub. No errors detected.

So I'm getting this error today and I've checked everything I can possibly think of, and can't for the life of me figure out where it's coming to this conclusion that there's something wrong with my Cache. All 3 drives are reporting healthy in SMART (has nothing really to do with Filesystems, but worth it to know), the drives are mounted, I'm able to copy to/from and edit files that are on the cache, etc. However, I do know something somewhere is wrong because my Docker's are failing randomly with I/O errors. Radarr has been notable: "message": "disk I/O error\ndisk I/O error", Deluge is showing files as downloading though they've done been downloaded already which is weird (manual torrents, so it's not radarr/sonarr related), etc. Alot of weird things that I can only imagine are coming from the cache. Another article i saw with a similar case referenced to go to the wiki on checking filesystems via the webgui. The link itself failed, but I was able to find the relevant wiki and this is what I get: "If the file system is BTRFS, then make sure the array is started, and NOT in Maintenance mode." However the cache page says: " Check is only available when array is Started in Maintenance mode." so I'm at a loss with that. I haven't tried filesystem checks on the other guys yet though because I haven't put the array in maintenance yet. tower-diagnostics-20190317-0006.zip

Surprised to be able to say this, but drive was brought online, parity rebuild ran, and all my recovered data survived. While there was certainly some data loss in the form of top level directories and some random source code (found a lot of random node_modules folders) for the most part I've recovered what I believe is 99% of all my expected data. Thanks a lot guys, some definite hard lessons were learned here!

Backup went way faster than the restoration via UFS. Fingers crossed, rebuild is starting now. Thus far, looking at /mnt/disk4 I definitely see all the (new) data there, so I think I'm in the clear for now. Basically not going to touch this thing for the next 8hours or so.

Very true, thanks. I picked up an additional drive and currently going through rsync to move the data. Hoping that in the next 3-4hours I'll be able to bring the drive back online and get the array back into parity.

@johnnie.black or @jonathanm, So with the recovery of basically all of my files. Is it safe to store them onto the array right now, while that drive is still disconnected? That's where I've been storing things (I only have about 600GB of freespace on local machine), but noticed an odd thing on unraid that the Free Space of the array has never changed, so I'm worried that putting the drive 4 back in, after all of this recovery, will result in dataloss again.

Awesome suggestion with the UFSExplorer, best spent money yet! Majority of my files were found after having it run continuously and only look against SGI XFS. I thought the real corruption would come in terms of .isos and archives, but the ones I've gone through so far appear to be working out. Haven't yet tried the vmdks, as they're still restoring, but awesome sauce. Should have my data backed up and the drive put back into the array tonight. Thanks guys

So it looks like UFSExplorer may actually do the trick. Doesn't appear to be able to maintain folder structure integrity, but I am getting filenames and it has start/stop/save capabilities. Also has the ability to only search for XFS filesystems rather than all (testdisk/photorec was finding old Mac data from I guess my VMDKs on the drive?) So this may get me as far along as I can hope for.

You're right, perhaps that was an incorrect wording to say, but testdisk has been shown to restore deleted partitions before or atleast provide files of such so that's my current hope. I'll check out the ufsexplorer, aint nothing to lose haha. Thanks both of you guys for prompt responses, and johnnie for providing the links to show the correct steps I should have taken! Appreciate it guys.

That's what I was afraid of. My hope right now is testdisk can find the missing partition and restore it. I've attempted Partition Wizard, but that doesn't recognize the XFS filesystem and I didn't want to restore the wrong on (it was finding ext2, 3, and 4) partitions which seems strange since the disk only had 1 partition in unraid. Do you have any recommendations for recovery other than testdisk?

Hey guys, So, I should preface this by saying that I am solely responsible for the piss-poor response I gave when I was faced with a disabled disk. I have 1 parity, and 5 disks in the array, and realized that 1 (disk 4) was disabled. SMART was showing as good, but for whatever reason the filesystem couldn't be read. I took the following steps (following no guidance, just my own trial and error, whereas I should have asked for help) I attempted to stop the array and start it again to see if that'll fix it. When that didn't work, I then had the idea that if I format the drive, it would be "enabled" and the parity would put the data back. However, format did not do this, and instead just created a blank drive. I currently have the drive pulled and am running "Testdisk" to see if I can pull and recovered files from it, but have the following questions. 1) I noticed that 2 shares disappeared completely. These appear to have originally been primarily stored on this disk, but its just strange that the share config itself is missing from the GUI. Does that sound normal? 2) Currently I don't get any "parity-checks" any more but instead "read-checks". Are these the same thing and maybe just an update that I never noticed before? 3) I'm not quite sure why the parity didn't replenish the drive, nor could I find (via just google) any manual action to get the parity to force a rebuild. I thought maybe a reboot would have done this, but it didn't. The "Emulated" contents only showed about 3GB of data rather than the 1-2TB that was originally there. Is there a way to verify if the parity still knows of or is able to rebuild this data? 4) VMs were for some reason disabled during all of this as well, even though VMs themselves didn't appear affected by any of this. Enabling VM Management started up my two VMs automatically. Currently Disk 4 is still removed from the array. Attached is my diagnostics, but I should note that its from after a few reboots and the drive being pulled a few boots ago. So I completely understand if I fubar'd the situation, but if there's like a step or something that I'm missing (particularly regarding #3 as it'll save me from waiting another 5days for TestDisk and Recuva to recover unstructured data). tower-diagnostics-20190217-0254.zip

Just for continuity and ease of use, I found this thread because it was number 1 in Google without much of a clear answer than Settings. Settings => Scheduler => Mover Settings => Move now