dozerplex

Parity check finished. Formatted disk 9 and its in the array. Seems to be using 400GB of data post-format compared to the usual 153GB and has a 53 billion writes to it. Everything seems happy so far, was a good test if nothing else. Thanks for the help guys!

Well that's the thing.. Definitely haven't dragged/dropped to a different share, only have the one mapped. Everything copied across is 'precious' media files which I'm quite careful with. No docker containers installed and no programs that would move/delete data are running. Trying to rack my brain to think if I've done any major deletes over the last few months to re-copy things for some reason, one occurrence springs to mind but the situation could be completely fabricated as you have incepted the idea that I have deleted something. Obviously it didn't just do it itself... Guess this is going to just eat me alive. Thanks for the help guys, will keep you posted regarding the unmountable drive.

I'd know if I removed 3-4tb worth of data. Is there logs I can access for that drive that may give us a clue?

Maybe it wasn't... /dev/sda1: LABEL_FATBOOT="UNRAID" LABEL="UNRAID" UUID="1B22-2846" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="ff68e290-01" /dev/md1p1: UUID="08da9a14-c0ba-425e-826b-8f543113d7ec" BLOCK_SIZE="512" TYPE="xfs" /dev/md2p1: UUID="ad40ee31-afc3-42f4-9f91-8abdee2f3ba0" BLOCK_SIZE="512" TYPE="xfs" /dev/md3p1: UUID="be895efa-a0e9-482c-b4f7-314e2b95d913" BLOCK_SIZE="512" TYPE="xfs" /dev/md4p1: UUID="54eb373e-542e-43f4-b2b0-dcc09ce3bbe8" BLOCK_SIZE="512" TYPE="xfs" /dev/md5p1: UUID="d5f2d458-1dc5-4555-b9a6-1cfe38768740" BLOCK_SIZE="512" TYPE="xfs" /dev/md6p1: UUID="7ad458ab-76a6-4899-85b6-797aa5368b8a" BLOCK_SIZE="512" TYPE="xfs" /dev/md7p1: UUID="f9ddb378-d196-420d-9abc-525002ac53f8" BLOCK_SIZE="512" TYPE="xfs" /dev/md8p1: UUID="b27299f6-82f2-4f85-b004-d3d8429b2d22" BLOCK_SIZE="512" TYPE="xfs" /dev/loop1: BLOCK_SIZE="131072" TYPE="squashfs" /dev/nvme0n1p1: UUID="6b7c90a9-8fd1-4780-a8b1-b8cb4fabe8eb" UUID_SUB="032ec031-b254-4cb9-ac26-53286d7be59d" BLOCK_SIZE="4096" TYPE="btrfs" /dev/nvme2n1p1: UUID="6b7c90a9-8fd1-4780-a8b1-b8cb4fabe8eb" UUID_SUB="958e6a7f-96fd-4f96-9d40-ac3de7ea224e" BLOCK_SIZE="4096" TYPE="btrfs" /dev/loop0: BLOCK_SIZE="131072" TYPE="squashfs" /dev/loop2: UUID="0c6f54cb-1117-4c77-9f0c-57d73929a089" UUID_SUB="76da6356-0436-447c-a7c2-6a5dfe18d616" BLOCK_SIZE="4096" TYPE="btrfs" /dev/loop3: UUID="e7bfabf3-b6ae-49f5-ad73-feefa5930133" UUID_SUB="135ceea0-83ed-4b7e-b95e-c463a02902f5" BLOCK_SIZE="4096" TYPE="btrfs" I guess I'll just format it when the parity sync completes? Nonetheless, the primary concern is where the hell my 3tb odd of data on disk 1 vanished to.. any insights?

unraid-01-diagnostics-20250326-2020.zip Replaced one today in an old R710, it definitely asked to erase before re-adding to the RAID6 array, my mistake for incorrectly assuming how parity function's. Thanks for the continued advice, learning as I go with all this. Please find diagnostics attached.

Assuming that's unraid specific? I would have assumed it would have formatted the drive in XFS before trying to mount it then correct with parity data like regular RAID? Sorry to be a pest, but which log files would you need? Would prefer not to post identifying information, are you able to give me a slimmed down list so I can obfuscate anything identifiable? If not, I'll go through and adjust a few serial numbers and whatnot. Appreciate the assistance!

Thanks JorgeB, I would've assumed that a brand new disk with a new fs would have fixed the issue. Why would the same issue appear across 2 new disks? Open to any and all suggestions over what (or whom) could have moved data specifically from one disk in the array, and to where? I've got no movers configured for cache/array or array/cache, one RecycleBin plugin and I'm the only one with administrative access. As far as I can tell at a glance no data is missing from the array but there's potentially 100tb to sift through. Edit: It appears to be rebuilding data, but no data would have been lost as Disk 9 (replaced) had no data on it. Up to 2tb being rebuilt so far but not seeing an increase in storage utilised? Still in the testing phases of unraid, this being part of the tests I had planned before putting it into 'production' so any insight would be appreciated. Should've done this with 2-3 drives but everything looked pretty solid until now. Still better to fiddle with it now than in 6 months when its my primary server.

Hey guys, New to Unraid, in the process of migrating and consolidating. Added my second parity drive the other day and the latest data drive - Disk 9, was showing 'unmountable: wrong or no file system. After the parity drive added successfully, I swapped Disk 9 out with a spare drive I had laying around to test if my breakout cables were bad. New Disk 9 is showing the same unmountable error. There was no data on disk 9 so I wasn't worried about losing anything. Started the array after swapping the disks (unassign, shutdown, assign) and Unraid is rebuilding from parity which will take 30 odd hours. Strangely, Disk 1 has dropped from 50% usage with 11tb used down to 7.5tb used... Disk 1: 7.5tb used Disk 2-6 11tb used Disk 7: 8.24tb used Disk 8: 153GB used Disk 9: unmountable If it explains it, Parity 1 is 22tb, Parity 2 is 24tb. Waiting on my next 24tb disk to arrive to replace P1. Any idea what's going on?

Hi, In the process of setting up my first Unraid server, upgraded to 7.0.0-rc.2 and enabled your plugin. Enable Recycle Bin is set to yes, no exclusions. Shares Is blank. Created/deleted a text document and no .Recycle.Bin folder showed up (per above comment). Hide Recycle Bin is set to No.