Drive not detected as part of pool

[51d]

Hi folks so recently I was in the process to move my media from stablebit to unraid and while I was being done with removing the last drives from the pool, I turned off my computer but I disconnected the wrong drive before starting it. After realizing it I turned off the machine and replaced the right drive.

The problem is now that the drive was recognized as non-pooled and when I tried adding it again its just detected as other non-pooled data within the pool.

What I did try:

Multiple shutdowns/restarts

Resetting all settings

Reboot + clean uninstall/install

The drive is still marked as full of data but that data seems non accessible from the drive itself. In the past I moved drives from machine to machine with no issues. I never had a problem in 6-7 years until I decided to move stuff around to disconnect drives from the pool.

It's recognized by all other software and what not. Stablebit scanner does not see any errors as well.

I enabled logging so I will submit what I got. Let me know if you have any clue folks. Thanks again.

 

ErrorReport_2025_02_03-01_20_23.8.saencryptedreport DrivePool.Service-2025-02-01.log

DrivePool.CoveFs.Boot.etl DrivePool.CoveFsDisk.Boot.etl

[51d]

I wanted to add that I tried assigning a letter to the drive and access the files from the poolpart folder before re-adding it to the pool there was nothing named .poolpart and after adding it to the pool it created a new one but I cant see the old version that contains my files.

Mind you originally that drive was part of the pool with no issues whatsoever.

Files seem to be still there and taking space, no way 12.3tb can just disappear I guess surely there is a permission thing going on or something if I can't see them even when showing hidden files?

Any kind of powershell sorcery would allow me to see these files again? I don't care about them being part of the pool anymore since I am moving to unraid, I just want to access them so I can move them out.

Thanks for any clue.

[Shane]

It could be the NTFS permissions are borked. Try https://community.covecube.com/index.php?/topic/5810-ntfs-permissions-and-drivepool/ (first two posts) to see if reveals the missing hidden PoolPart.guidstring folder?

 

[51d]

I want to look into this immediately but I was running a scan with Stablebit Scanner so once it's done I will let you know but these posts seem to make sense, I just hope they will apply to my situation as well.

Should I just stop the scan because I'm not so worried about the disks sectors but I was hoping that the file system check at the end of the scan might help? If not the case, I might as well cancel it right away.

I will let you know whether it worked or not.

Thanks again.

[51d]

So I did reset of the permissions and it still not working...

The only poolpart folder i'm seeing is the one from when I attempted to re-add the file to the pool and is empty, yet everywhere it shows that my drive is still 12 tb full....

[51d]

I recovered it by using a regular 30 seconds disk drive scan in the properties tab which I find incredible to say the least! Thanks for the help though as the fix was easier than I initially thought.

```

Chkdsk was executed in scan mode on a volume snapshot.  

Checking file system on M:
Volume label is EXOS_SATA_2.

Stage 1: Examining basic file system structure ...
  136448 file records processed.                                                         File verification completed.
 Phase duration (File record verification): 3.77 seconds.
  11868 large file records processed.                                     Phase duration (Orphan file record recovery): 5.13 milliseconds.
  0 bad file records processed.                                       Phase duration (Bad file record checking): 0.64 milliseconds.

Stage 2: Examining file name linkage ...
  128 reparse records processed.                                         149924 index entries processed.                                                        Index verification completed.
 Phase duration (Index verification): 11.28 seconds.

 Phase duration (Orphan reconnection): 12.50 milliseconds.
    Found lost file "<0x1,0x28>"; requesting reconnection to index "$I30" of directory "\ <0x5,0x5>"
        ... repaired online.

 Phase duration (Orphan recovery to lost and found): 12.09 milliseconds.
  128 reparse records processed.                                        Phase duration (Reparse point and Object ID verification): 4.82 milliseconds.

Stage 3: Examining security descriptors ...
Security descriptor verification completed.
 Phase duration (Security descriptor verification): 22.34 milliseconds.
  6739 data files processed.                                             Phase duration (Data attribute verification): 7.89 milliseconds.
CHKDSK is verifying Usn Journal...
Usn Journal verification completed.
Windows has found problems and they were all fixed online.
No further action is required.

  15259645 MB total disk space.
  12984412 MB in 73609 files.
     28672 KB in 6740 indexes.
    679835 KB in use by the system.
     65536 KB occupied by the log file.
   2274541 MB available on disk.

      4096 bytes in each allocation unit.
3906469375 total allocation units on disk.
 582282643 allocation units available on disk.
Total duration: 15.12 seconds (15126 ms).

----------------------------------------------------------------------

Stage 1: Examining basic file system structure ...

Stage 2: Examining file name linkage ...
CHKDSK is scanning unindexed files for reconnect to their original directory.
Recovering orphaned file PoolPart.81f616f5-be54-46c7-93f3-f25ebce744e6 (28) into directory file 5.
Recovering orphaned file PoolPart.81f616f5-be54-46c7-93f3-f25ebce744e6 (28) into directory file 5.
  1 unindexed files recovered to original directory.

Stage 3: Examining security descriptors ...

 

```