LordRaven

Followed the instructions in this video from SpaceInvader One: Ended up having to clear the logs and then it came back up.

Hi all, I initially noticed this during a parity check that was going on my system where Disk 4 dropped while I was just just trying to erase a file. I waited for the parity check to finish then rebooted but when I came back, it still shows as follows: The last time this happened, I redid the configuration as suggested in another post and it was working fine. This is the second time this has happened but its a brand new drive so I'm not sure why. I'm attaching a copy of my diagnostics if anyone can make heads or tails of it to let me know what I may be missing. datastore-diagnostics-20230610-2202.zip Thanks, Raven

Not sure why, but I stopped the array, shutdown, removed the old disk Six, restarted with the new config and tried again and everything now came back. Just thankful for small miracles I guess.

Looks like the data is well and truly gone. Just had to do the parity again and thats it I guess. Should have some old backups for most of the data but lesson learned. Still would like to know what killed it in the end.

Initially they weren't both being emulated. The Four was as it was rebuilding but should have been almost done. I just came home and found them errored out and being unmountable. When I tried to put it back on after a reboot its when I started encountering the issue with emulation. I'll try and see what happens when I get home and hopefully something good will occur.

Sorry you're right. I mistyped when I said pre-cleared. It was just trying to clear the drive.

Hello all, Recently I had two drives go bad within a relatively short time of each other. I had replaced them individually. Drive Six which was my first one to go bad was replaced and per the normal, it went into an emulated mode while it restored the contents and everything was good. Drive Four also was acting up but because Six had more info, I made sure to only do one at a time. After Six was fully done and working for a bit, I did Four. That started off normal and was mostly done. Last night, I came home and saw both Four and Six were offline and listed as Umountable with the encryption keys not working. Did a few reboots and restarts, putting the keys again without luck. The drives were being asked to be formatted. Read through the forums and saw the suggestions again for reboots, even tried removing them, restarting and putting them back in. In the end I went nuclear, and said to format knowing that it may lose my data. Four came back and is now working properly again with the old information. Six seems have done a full format and I guess I lost that data. However its still showing as having a problem but for the life of me I can't figure out what it is. Questions I have are this: Can someone help me figure out whats wrong with Six? Is the data truly dead and gone? Is there a possibility of it rebuilding like Four did? I still have the old version of Six, which I had put into a different slot and tried to connect to copy the information on it. It started to preclear but I stopped it, but how do I mount the old drive to pull the information off it again? Thanks in advanced, Ravendatastore-diagnostics-20230607-1853.zip

So I've switched the CPU and will report back on what happens. Just need to get a new licence key. I'll give this a month and assuming it works, will report the success and close this topic.

Thanks Trurl. It is a Ryzen, so I'll see if this helps.

Okay, fair enough. Is there a way to figure out what caused it to switch? Its a brand new USB only a few weeks out of the wrapper, and given I've had 3 go in the last month, I'm guessing its a config or some corruption in my setup. I'm hoping to figure out what's causing it so I don't have to rebuild my entire system from scratch as if I was setting up a brand new machine.

Does anyone know if there's a way to switch a USB back to read/write in Unraid? I'm assuming I could try the other method via a Windows that I've seen online, however I know with my previous attempts it didn't work and I'm kind of not wanting to risk shutting down my server if it means it won't atleast limp by like its doing now.

Yup, its definitely a USB2 flash drive in a USB2 port.

Hi guys, I'm been having an issue with my Unraid for about a month, and not sure what could be causing it. I'll apologize now if this is a bit long winded or rambles a bit, but I thought I'd document everything since this is driving me nuts. The situation is that I keep having USBs go to read-only. The first one was the original USB and after 6 years, I figure had done its time. The next was probably my fault for using a USB3 rather than 2, and fair enough. This one however, is definitely a USB2 and nothing was going on out of the ordinary. I'm attaching a copy of the diagnostics which hopefully someone can see something I've been missing. The latest USB was completely brand new about two weeks old. I am on Unraid 6.8.3 and all my dockers and various other sub-systems are typically up-to-date. Hardware wise, the only changes from the original USB going kaput is put in some new fans to keep the system cooler and moved a Video card in so I could use a VM as my main machine. Current specs are: Motherboard: Gigabyte Technology Co., Ltd. B450 AORUS ELITE Bios: vF50 (one less than current since I coudn't get that to install properly.) Memory: 64Gb Log from the USB Drive is only: Jun 17 23:54:21 DataStore kernel: sd 0:0:0:0: [sda] 30548096 512-byte logical blocks: (15.6 GB/14.6 GiB) Jun 17 23:54:21 DataStore kernel: sd 0:0:0:0: [sda] Write Protect is off Jun 17 23:54:21 DataStore kernel: sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00 Jun 17 23:54:21 DataStore kernel: sd 0:0:0:0: [sda] No Caching mode page found Jun 17 23:54:21 DataStore kernel: sd 0:0:0:0: [sda] Assuming drive cache: write through Jun 17 23:54:21 DataStore kernel: sda: sda1 Jun 17 23:54:21 DataStore kernel: sd 0:0:0:0: [sda] Attached SCSI removable disk Jun 17 23:54:56 DataStore emhttpd: Verbatim_ToughMax_1317110000000623-0:0 (sda) 512 30548096 Jun 17 23:54:56 DataStore emhttpd: import flash device: sda Jun 24 05:07:02 DataStore kernel: FAT-fs (sda1): error, invalid access to FAT (entry 0x0f7ffff7) Jun 24 05:07:02 DataStore kernel: FAT-fs (sda1): Filesystem has been set read-only I haven't rebooted the machine yet to see if that makes a difference since in the previous cases it hadn't and I thought I'd leave it on in case anyone has an idea I need to check. This latest case came up overnight and nothing apparently out of the ordinary was going on. I had just finished using the machine earlier, went to bed, and in the morning, my phone notified me the USB flipped. datastore-diagnostics-20200624-0746.zip

Hi, Just for anyone who has a similar issue to what I had. I had a disk being unmountable. Disk is a default format of xfs. After checking the disk, I found that it had a metadata corruption. The fix was in maintenance mode to run the xfs_repair with the -Lv option. The L is for force the zeroing of the log file on the disk. I know that the in the xfs_repair screen (https://lime-technology.com/wiki/index.php/Check_Disk_Filesystems#xfs_repairmention that it isn't one of the options we probably need, however this was the only way to fix my disk and allow it to be mountable again. Thanks, Raven

Just wanted to throw this out as a solution if anyone has the same issue I had. I'd put in the Syncthing docker on my machine and using the bridge connection mapped 8080 in the docker to my towers 8082. Unfortunately, what happened was that the system was not able to connect to any of my other Syncthing instances on other devices no matter how much I put the ID's on the tower instance or on the remote instances. The issue turned out to be needing to have 8080 mapped from the docker to the tower instance. Once I did this, the mappings started coming through. I had not originally done this because I was running unmenu on port 8080. I had to edit the unmenu.conf file to change the port there and everything is now up.