Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In with Google


No poll attached to this discussion.

In order to better support our growing community we've set up a new more powerful forum.

The new forum is at:

The new forum is running IP.Board and will be our primary forum from now on.

This forum is being retired, but will remain online indefinitely in order to preserve its contents. This forum is now read only.

Thank you,


edited August 2011 in DrivePool

I'm seeing some very strange permissions behaviour at the minute.

Most of the time until now, I've been moving around files using Remote
Desktop and there has been no issues.

I have a couple of users set-up and have even given the Guest account full
Read/Write access to most shares.

Yesterday, I was trying to view a downloaded TV program but one of my HTPCs
was not able to access one of the shares (even though I checked and the Guest
account had read/write access to that share).

I then checked another couple of shares and they were accessible from this
HTPC, so I went back to the RD session and moved the folder with those files in
to one of the shares the HTPC could access.

After moving the files to the next share, that share also then became
inaccessible to the HTPC (same happened again with the next share). So it was
definitely related to moving files around and it somehow breaking / impacting
the permissions.

The strange thing is, when I look into the permissions settings on either
User, Folder or Drive Pool tabs, it shows the Guest account as having R/W access
to these folders.

Any ideas? Anyone else seeing anything weird like this?


  • having same problem. some of the PCs in the network can access the pool and others cannot. What is even more weird is that on the same computer, one of user accounts can access pool shares and the other account could not. 

    Everything is under home group, guest account enable, everything set to R/W access....
  • Resident Guru
    Might be worthwhile to examine the NTFS security settings of the files on the server itself (not DrivePool's share permissions, the NTFS permissions on the files/folders on the server's physical disks)?
  • I used to reset NTFS permissions to have "Everyone" to have Full Control of entire disk drive and also made this setting to propagate all the way to descendants.  Still can't think of a reason why can't some of the PCs/users connect to shares...
  • Yeah I'm seeing the exact same problem on my setup as well. I have 5 pooled folders, where 1 PC can acces it (Win 2008 server) whilst my Win 7 MC can't! Using different user names. Even when using Homegroup it fails as well so that's suggesting it's permissions higher up in the tree and no the sub folders themselves.

    Unfortunately this has pretty much made my pooled drives useless as it can't be accessed by other PCs.

    I'm testing a few things resetting permissions...will update if i work it out.

  • OK think i've found a fix which seems to have allowed my PCs to access the pooled folders.
    Version: Beta M3.

    Problem: Creation of new pooled folders doesn't propogate permissions. This results in users to be unable to access pooled drives. (Guests / everyone / legit users all fail).

    Background: Stablebit uses Microsoft's DFS to mount folders. It puts mount points in the folders
    C:\ServerPool\ServerFolders and

    If you go into the 'links' in C:\ServerPool\ServerFolders ...the subfolders in there (Pictures\Movies\etc) may already have the correct NTFS permissions. However it's the links themselves which may not have been properly permissioned which results the Access is denied error.

    Fix: Simplest fix, (It may not be the most secure as it depends on whether you want granular folder permissions) is to go to the property of the C:\ServerPool folder, Security settings and add the 'Everyone' Group, with Read/Write permission. 
    This should proprogate to the subfolders / links. 

    Now check a link to confirm eg C:\ServerPool\ServerFolders\Pictures. If the Everyone permission is not there, add it once again for that link, and everyone other link (its effectively the pooled folder name) you have. 

    I've also had to add 'Everyone' to the C:\ServerPool\ServerFolders.Mount link.

    Let's hope CoveCube come up with a fix. As i created a new folder in stablebit console and it still has the same problem. Initially i thought it was my install from upgrades from previous beta versions. 

    Let me know if it works

  • Covecube
    Permission should be getting set on the mount folder and then propagated up to the link. I've just checked the code briefly, and that's what it says.

    Perhaps it's not working. Will do further tests.
  • I had the same problem. I fixed it with changing the security settings in the Dashboard, but on the Server Folders and Hard Drives tab, and the share/folder in question. I just changed the permissions for the user in question, and set it back again. If I remember correctly this folder/share in question was the only one I created with Stablebits. I tried to reset the permissions in the Stablebit interface first, but that didn't work.

    Sounds like a wee litt le bug this :)

  • I think I have some issues related to permissions as well. On my router there is a CFIS share setup. This had been working and I upgraded the firmware on my router. Something must have changed a little in the firmware for the CFIS because there were a couple more options like choosing the type of security. I have it set to NTLM. I verified under network setting on the server support for NTLM was on. I have a duplicated folder on the pool called Logs. The CFIS won't mount and I am not getting any errors in the router log. If I move the folder off the pool it will mount, but if I move it back on it will not work.  I am running 3790.
  • Covecube
    @eagleknight: You will need to collect logs at the point of failure.


    This is a little more complicated than error reports so I suggest you open a case @ and I'll guide you through it.
Sign In or Register to comment.