Flamingo

I know this is an old thread but I run into this issue today. This is definitely something to do with UNRAID. I found a solution however that was working in my case. I had most of my shares working fine but a newly created share had the same issue as @HHUBS. I ended up writing both the share and SMB settings from a working share to the new share that wasn't visible on the network and presto the issue was resolved. I hope this might help someone in the future.

Thanks JorgeB, I swapped Disk3 with a new disk and started the array. The parity check/rebuild is now running. The old content of Disk3 will not be rebuilt in my opinion. First when I started the the server with the new disk the array was started with Disk3 simply just missing. I would imagine if the parity drive would have been intact the old content would have been emulated immediately. I stopped the array and added the new 8tb disk to it. The contents are now emulated but when I browsed them I only saw the lost+found folder. I imagine it will repopulate that data. Also when Disk3 was repaired (check -L) yesterday and the lost+found folder was created I have a feeling it overwrite a large chunk of the disk with the contents of the lost+found folder (about 2.5 tb), so trying to recover the content of that physical disk is questionable. What is your opinion?

Thanks JorgeB, Could you please kindly explain me the below steps in detail so I can follow them First you need to rebuild the emulated disk, and parity will agree with that rebuild. You can still try to recover the partition on the actual disk with testdisk, and if successful you can mount it with UD after changing the XFS UUID, that can be done in the UD options.

Hi All, Just a quick update on the process. Following the completion on the Check -L repair I started up the array as normal. The contents of Disk3 seems to be emulated There is a lost+found folder present with a significant amount of content. I'm in the process of copying the lost+found folder to an external location. Once the copy is completed I'm planning to start a parity check as I think the parity drive was impacted as well and it would be important to rebuild the parity. I think I managed to recover most of the data that was originally stored on Disk3, but now I have the task of sorting everything as all my existing folder structure with the name of the actual folders are gone. If I left out anything or if anyone have any suggestions please let me know.

The process completed There is quite a lot of information in the output. Can someone please check this if it looks OK, and advise what would be the next step? log14APR2022.zip

Thanks itimpi I started a check -L I will check the results in the morning.

This is the result of the second check: Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... verified secondary superblock... writing modified primary superblock - block cache size set to 6116280 entries Phase 2 - using internal log - zero log... zero_log: head block 1429578 tail block 1429576 ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. Could someone please advice what would be the next step?

Thanks JorgeB, I run the check -v command now. I will post the outcome here.

Thanks JorgeB, I stopped the array and restarted it in maintenance mode. I run the check -nv command and this is what I got back. Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... .......................................... verified secondary superblock... would write modified primary superblock Primary superblock would have been modified. Cannot proceed further in no_modify mode. Exiting now. What attribute should I run the check command to allow it to write a modified primary superblock? I think I should use check -d Does anyone have experience with this command in a similar situation?

How can I correct/recreate the partition table on disk3? The raw data should still be present on the disk so should should be largely a logical issue, no?

How can Disk3 be emulated and un-mountable in the same time?

tower-diagnostics-20220413-1348.zip

Sooo I messed this up big time. My initial assessment was correct. Steps I took in the past hour - I stopped the parity check. - turned off the server - disconnected disk3 - powered on the server - unraid started, the array didn't start. I found it strange it didn't try to emulate Disk3. I opted for the array to be started as I tough emulation might kick in after...at hat point I realized that my original assessment was correct. When I was working with the 2 disks connected to the VM and I removed and reconnected one the disk allocations must have changed without me realizing it. And when the VM started for the second time not the two unassigned disks were connected but the parity disk and Disk3. - I turned off the server again - reconnected Disk 3 The array didn't pick the disk up automatically after the reboot. Probably because the partition table was missing. - I added Disk 3 as a new config. The disk is now in the array sort of but not mounted. I have n I have no idea how the parity disk is is green?!? I have a feeling I have deleted the partition table from that accidentally as Disk3 was never emulated. Data should still be present on Disk3 but now thinking back I might have reformatted as a quick format to ntfs. Is there a way to restore this?

I got an error from Fix Common Problems. I don't think currently the parity disk can write to it. Should I just wipe the disk and reconnect to the array. Since only one disk is impacted the parity disk could rewrite the data

Unraid was working flawlessly so far and still is. I messed it up... Since no formatting happened I hope I can get back the data. Most of my family pics and old scanned documents are on that drive...🙁

Hi JorgeB, Please see the diagnostics attached. tower-diagnostics-20220413-1237.zip

Just a quick update. I seems that only 1 disk was impacted from the array (sdf). I think when I removed on of the replacement disks physically from the server one of the disks from the array jumped in it's place. And when I reconnected the physical disk the disk from the array remained amounted with the VM. Parity check is running. I'm not sure if it will be able to replace my missing files given the partition table is messed up on sdf. Please let me know if you have any suggestions on this.

Hi fellow forum members, I made a mistake and I only realized my error a minute too late. I have 4 8TB disks in my array and an additional 8TB disk that was mounted to a VM. I was replacing the disk mounted to the VM (both old and replacement disk was present) but in the process somehow two disks from the array got mounted to the VM. I can't think of how it happened. While I was working on the VM I noticed there was some issue with the disks and I cleared them with diskpart in windows. This of course made all the data disappear on the two disks in the array. The parity seems to be ok. I started a parity check. The disks seems to be indicating the old data still being present as they seems to be half full on the dashboard. I busted the partition table on the 2 disks from the array for sure but there was no formatting took place in diskpart. I think all it did was deleting the partition tables. How can I restore the original partition table so the data is visible to the array again? Please help as I'm in a bit of a panic... Thanks, Flamingo

Thank you both for the answers, much appreciated.

Hi, I have a strange issue. I created a new user and specified a password during user creation. When entering the User settings the password field is empty. However when I try to access a share using the new user account I need to use the password I specified during the account creation to access the share. Also with this account I can't enter the web interface. The password is not accepted and using an empty password field isn't working either. Any help will be much appreciated.

Indeed I do. The problem is now on the hardware layer. I think I need to order a new mobo...

The problem with this that I'm having difficulties accessing the bios on the mobo... (sadface lvl99...) this is a know issue with some of the X8SIL boards. I need to figure this one out somehow.

The problem with this that I'm having difficulties accessing the bios on the mobo... (sadface lvl99...) this is a know issue with some of the X8SIL boards. I need to figure this one out somehow.

This might be the problem!

Addingtower-diagnostics-20190801-2021.zip the diagnostics.zip if anyone can help. Does anyone know where can I download earlier versions of Unraid? From late 2018...for testing.