Jump to content
Covecube Inc.


Spend long enough working with Windows and you may become familiar with NTFS permissions. As an operating system intended to handle multiple users, Windows maintains records that describe which user owns each file and folder and how much access each user has to those files and folders. These records are kept on the same volumes as those files and folders. Unfortunately, in the course of moving or copying folders and files around, Windows may fail to properly update these settings for a variety of reasons (e.g. bugs, bit errors, power interruptions, failing hardware).

This can mean files and folders that you can no longer delete, access or even have ownership of anymore, sometimes for no obvious reason when you check via the Security tab of the file/folder's Properties (they can look fine but actually be broken inside).

So, first up, here’s what the default permissions for a pool drive should look like:

Screenshot of the default permissions for a pool drive.

And now here’s what the default permissions for the hidden poolpart folder on any drive added to the pool should look like:

Screenshot of the default permissions for the hidden poolpart folders that form a pool.

The above are taken from a freshly created pool using a previously unformatted drive, on a computer named CASTLE that is using Windows 10 Professional. I believe it should be the same for all supported versions of Windows so far.

  • Any entries that are marked Deny override entries that are marked Allow. There are limited exceptions for SYSTEM.
  • It is optional for a hidden poolpart folder to Inherit its permissions from its parent drive.
  • It is recommended that the Administrators account have Full control of all poolpart folders, subfolders and files.
  • It is necessary that the SYSTEM account have Full control of all poolpart folders, subfolders and files.
  • The permissions of files and folders in a pool drive are the permissions of those files and folders in the constituent poolpart folders.
  • Caveat: duplicates are expected to have identical permissions (because in normal practice, only DrivePool should be creating them).

My next post in this thread will describe how I go about fixing these permissions when they go bad.

Link to post
Share on other sites

5 answers to this question

Recommended Posts

  • 0

Edit: https://wiki.covecube.com/StableBit_DrivePool_Q5510455 is the normal, Stablebit-approved method to reset NTFS permissions. It should suffice in most cases, and it's easier to do than my method, so try it first.

To fix broken NTFS permissions I now use a freeware program called SetACL because - at least in my experience - it properly supports both long paths and unicode and can fix damaged security records that Windows builtin tab and utilities like takeown and icacls can’t (for reasons that personally I boil down to “unicode and long paths were added to Windows partly via the programming equivalent of lots of duct tape”). If you're a sysadmin I recommend checking out the rest of the site too!

The following is a quick guide to how I use SetACL to reset my pool permissions on my own machines. Your mileage may vary; you should always have backups of anything you don't want to lose.

Note: if you have customised your pool's security permissions (e.g. for multiple users with different access rights) be aware that you may need to customise the following commands (particularly the fourth) in this post to suit your changes, or adjust the permissions subsequently.

I download the SetACL for Administrators (not the Studio) from here. It's freeware (as is the Studio version if you want a GUI). Open the zip file and copy SetACL.exe from the 32bit or 64bit folder (as appropriate) to wherever you want to keep it so long as that location is OUTSIDE of your pools.

Open a command prompt as an Administrator and enter the following commands in order (where X:\ is the location of SetACL.exe and P:\ is the location of your pool drive - and that's very important, do not get confused, do not put in the wrong drive letters):

Net stop "stablebit drivepool service"

X:\SetACL.exe -on P:\ -ot file -actn setowner -ownr "n:Administrators" -rec cont_obj -fltr "System Volume Information" -fltr "$RECYCLE.BIN"

X:\SetACL.exe -on P:\ -ot file -actn clear -clr "dacl,sacl" -actn rstchldrn -rst "dacl,sacl" -fltr "System Volume Information" -fltr "$RECYCLE.BIN"

X:\SetACL.exe -on P:\ -ot file -actn ace -ace "n:Authenticated Users;p:change" -ace "n:SYSTEM;p:full" -ace "n:Administrators;p:full" -ace "n:Users;p:read_ex" -fltr "System Volume Information" -fltr "$RECYCLE.BIN"

Net start "stablebit drivepool service"

The first and last commands stop and start DrivePool respectively; the second command takes ownership (since you need to have ownership before you can alter any permissions that would otherwise prevent you from altering permissions), the third resets all existing permissions and enables inheritance of new permissions, and the fourth grants new permissions (I’ve used the Windows 10 defaults that should be compatible with all versions of Windows that are compatible with DrivePool); the special folders used for System Volume Information and Recycle Bin have been excluded as a precaution.

If you are still getting permission errors even after running all five commands in order, you can try running them directly on the individual poolpart folders. So for example if "E:" was one of the drives you'd added to the pool, you'd use E:\PoolPart.guidstring instead of P:\ in the above commands (tip: when you're using the command prompt, pressing the tab key after you've typed PoolPart into the command prompt should fill in the correct guidstring for you). Note: poolpart folders contain a ".covefs" folder; do not apply non-default permissions to that folder unless you know exactly what you are doing.

If your pool contains a lot of files (the size of each file doesn't matter), these commands may take a while to complete (my primary pool, with ~600k files, takes a couple of hours).

Link to post
Share on other sites
  • 0

I've occasionally had problems with using Windows own built-in security tab to fix pools where (very) long paths are involved and/or where the permissions have broken in a way that isn't repaired by the tab. And when the usual power combo of takeown+icacls didn't fix them either (and wow finding out "why not?" was a trip down a rabbit hole), that's when I went hunting and thankfully found SetACL (which is why I've finally gotten around to creating this thread). I have however now edited my second post above to mention the wiki article at the top.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...