Freshly formatted drive 'unable to enumerate folder'

[Phidaissi]

A freshly formatted drive with no contents at all is giving me an "Unable to enumerate folder" error when I try to edit folder duplication options, preventing me from changing them *at all*.

What I did:

• I removed a drive from my pool that had a read error.
• Formatted the drive (non-quick).
• Scanned the whole drive with scanner to see if error still occurred (it does not, reports healthy in scanner now).
• Added drive back to pool.
• Went to Manage Pool -> File Protection -> File duplication on the pool.
• Error popup saying, ""Unable to enumerate folder. Access is denied"
• No folders listed in file duplication box now (it works when drive is not in pool) so totally unusable.

This drive is totally empty, it was literally just formatted, and it was not a quick format so that format took many hours and destroyed anything that even theoretically was on the drive!

I checked the ownership of the drive, and is it owned by Administrators, there should be no access problem as far as I can tell.

The drive was previously in the pool before I reformatted and rescanned it to ensure the error was smushed, and I did not have this problem accessing file duplication - I have several folders configured to duplicate!

 

[Phidaissi]

Resolved, but it took a while to find the issue because nothing in the drive pool logs helped point to the source of the problem, and the behaviour of drive pool as mentioned above was a complete misdirection.

It turned out to be a folder on one of the existing drives in the pool had broken permissions.
For some reason this did not create any problems opening up the file duplication settings, unless I added the new drive. Even removing the new drive allowed it to work again. So the symptom of the issue was exclusively when the new drive was in the pool, but the error was caused by a folder on an existing drive.

No logs seemed to tell me much of anything. The logs don't mention the file or folder that caused the error. This seems like a massive oversight as this should be really easy to log and would have made the cause immediately apparent and saved a lot of time.

Likewise the log let me down when removing drives from the pool yesterday - when the same issue occurred and the only message I got when attempting to remove was 'access denied' and the drive failing to remove. I ended up removing it with the damaged option though and then moving the affected files back into the pool manually. It turned out that it was files with changed permissions not affected by drive removal yesterday that were already on a disk that stayed in the pool that ended up causing the issues after adding the drive back in. Despite the fact that they weren't on the drive added...

This could really do with better logging that actually tells us the file that caused an error to be thrown. At the very least, it makes tracking down the causes simple.

[Christopher (Drashna)]

That's very odd.  

Do you remember how the permissions were set? 

Also, if the disk had issues in the past, it's entirely possible that the permissions got corrupted, which could cause this sort of behavior.  Otherwise, this really shouldn't happen, normally.