Flamingo

Members
  • Posts

    38
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Flamingo's Achievements

Noob

Noob (1/14)

0

Reputation

  1. 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.
  2. 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?
  3. 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.
  4. 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.
  5. 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
  6. Thanks itimpi I started a check -L I will check the results in the morning.
  7. 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?
  8. Thanks JorgeB, I run the check -v command now. I will post the outcome here.
  9. 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?
  10. 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?
  11. How can Disk3 be emulated and un-mountable in the same time?
  12. 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?
  13. 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
  14. 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...🙁