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,

Permission issues on new server after migration from WHSv1

edited September 2012 in DrivePool
I've got an email into the support people regarding this issue, but as I was googling around on my own this morning I found this forum and thought I might get some insight here as well. 

Basic problem: all of my files in the DrivePool are inaccessible. VLC can't open videos, Word docs fail to open, etc. When I attempt to copy the file (using Explorer when I'm logged into WHS2011 via RDP) to the server's desktop, I get Error 0x80070780: The file cannot be accessed. When I open the individual drives and copy the same file, it works fine. 

What I've done so far: Everything! :) The history works like this:

- Installed WHS 2011 onto a new 2tb drive.
- Removed one of my 2tb drives from WHSv1 and installed it into WHS2011
- Added both drives to the DrivePool, without formatting or anything
- Created my Shared folders and moved them to the DrivePool via the Dashboard
- Copied everything in \de\shares from the WHSv1 drive to the DrivePool

At this point, copying data took an extraordinary amount of time. With another 8tb of data to go, I emailed support and they sent me directions to avoid having to copy it. So I went through the following steps:

- Added all my old WHSv1 drives to the WHS2011 server
- Added all the old drives to the DrivePool, without formatting or erasing them
- Killed the StableBit DrivePool service
- On each drive, I moved everything from \de\shares to \Poolpart.(x)\ServerFolders
- Deleted the DrivePool metadata in the \ProgramData\StableBitDrivePool\Service\Store folder
- Restarted the service
- Applied permissions for my users via the Dashboard
- Used the Windows Server Solutions troubleshooter tool and ran the "Reset NTFS Permissions on Pool" function (from here:
- Rebooted the server (the directions didn't include this step, but I figured it certainly couldn't hurt)

After the server booted up, I opened up \\servername and all the shares were there, along with all the data. However, none of the files would open. At this point I started some troubleshooting, and figured out that everything seems to work if I copy the file from the actual drive to the server's desktop, then back to \\servername\drivepool (note: I get the "file cannot be accessed" if I copy of the existing file, but it works if I put it into a temp dir somewhere else). I've been staring at permissions boxes all morning and can't see a difference in the files, though. 

I've also tried taking Ownership of E:\ (my DrivePool virtual drive) via the instructions at this link: but it hasn't worked either. 

Any tips? I'd love to get this solved! :)


  • edited September 2012 Member
    As an update, as I've been pulling my hair out all day over this, here's what I've done and what it has changed:

    - Killed DrivePool Service
    - Reassigned Ownership on each individual drive to the administrators group
    - "Replaced all child permissions..." on each individual drive
    - Deleted the DrivePool metadata
    - Restarted the service

    Surprisingly, this made *some* of the files work. Mostly my Music and Software share. Some documents (in the Software share) work and some don't. None of my videos seem to work. I can't find any rhyme or reason to it, either. I went through each physical drive to find the files that are working from my laptop, but while some files work on that drive, other files don't. Very confusing.

    I've gone through the server logs but don't see anything related to what I'm doing. Again, if anyone has any tips for me, I'd love them.
  • Ok, getting closer. I was comparing the files security settings and realized the following:

    - The files that work allow me to edit any security setting I like
    - The files that don't seem to think I don't have permission to change security settings unless I change the owner of the file, even though the file's owner is listed the same as the files that do work
    - The files that don't work DO NOT have the problem listed above if I view them from the physical drive, ONLY the DrivePool. 

    No amount of tinkering has let me change the permissions of the files that don't work. 
  • edited September 2012 Resident Guru
    Oh, the joys of WHSv1 "leftovers". :p

    Do you have physical access to the machine (i.e. keyboard, mouse, screen plugged in)? Try the following:

    * Uninstall DrivePool.
    * Boot into Safe Mode.
    * Delete the entire c:\ProgramData\StableBitDrivePool folder (or rename it, if support might want it)
    * On each individual drive, reset ownership to Administrators on the drive's PoolPart folder: bring up the folder's context menu (usually right-click), go to Properties, Security tab, Advanced, Owner, Edit. Choose Administrators, tick Replace, then OK, OK, OK, OK.
    * Again bring up its context menu, go to Properties, Security tab, Advanced, this time Change Permissions. Remove all non-inherited Permissions, tick Include and tick Replace, then OK, Yes, OK, OK.
    * (don't do these things to the root of the drive itself, just to the poolpart folder).
    * Reboot back into normal mode.
    * Reinstall DrivePool. Change the pool drive letter to whatever you had before you uninstalled, if it's different.
    * Reapply WHS share permissions via the Dashboard.
  • edited September 2012 Member
    Yeah I thought this wanna be a bit easier! :) 

    Before I uninstall DrivePool, I should double-check: that won't remove any data in the PoolPart folder, correct? 

    Edit: no, it doesn't. Proceeding through now. I don't have a mouse hooked up, but my keyboard shortcut skills need a workout anyway. 

  • Resident Guru
    That's correct.

  • edited September 2012 Member
    Still didn't work. :( 

    I followed your directions, but I might have messed it up at the very beginning. I uninstalled the add-in from Add/Remove Programs, then proceeded through the rest of the steps. When I booted back into normal mode and tried to install the add-in, it said it already existed. I had to open the Dashboard (DrivePool didn't have an icon) and remove it, then re-install.

    I'll try to redo the steps tomorrow after work, this time removing the add-in from the Dashboard first. 

    If that doesn't work, I'm thinking:

    - Uninstall DrivePool
    - Create a temp dir on the physical drive
    - Move everything from the PoolPart folder to the temp dir
    - Repeat for each drive
    - Install DrivePool
    - Choose a different letter for the DrivePool drive (I didn't like E:\ anyway)
    - Add each drive to the pool
    - Copy the data from the temp dir on each drive to the new DrivePool disk
    - Drink a lot of beer while waiting for stuff to copy

    Sure, it'll take forever, but it's all I've got left at this point. :) 
  • Resident Guru
    Yes, add-ins should be uninstalled via the Dashboard.

    Note that if you change the letter for the pooldrive, make sure you don't have any of the default WHS shares on it at the time.
  • edited September 2012 Member
    I tried it again after uninstalling from the Add-Ins tab of the Dashboard and it still didn't work.

    Something that confuses me, though: when I re-installed DrivePool, it still add all the drives joined to the pool, even though I removed the c:\ProgramData\StableBit folder. Is that because the drives all contain the PoolPart dir?
  • edited September 2012 Member
    As a follow up, I've got everything working. ALMOST. I won't go into all the details, but it involved uninstalling DP, rebooting, moving the folders in \PoolPart to a temp dir, deleting the \PoolPart dir, moving the Share Folders to a different a new location, rebooting, then re-installing DP, pointing the Share Folders back to the DP drive, and from there going through all the steps that support sent me for quickly adding the folders to the pool. Everything worked! Yay!

    During that, I narrowed down my permissions issue to certain files on one particular drive. These files simply won't let me overwrite their ownership info, despite it being listed as \servername\administrators. Some digging revealed that they all share similar file attributes: AL, APL, APLI. Some further digging leads me to believe that at some point in this whole three day process, I overwrote the actual files on this drive with the WHSv1 tombstone files. Some of the files weren't overwritten, luckily. 

    I could use some help, though:

    - I need to find a way to generate a list of files that exist on this drive (K:\) that are not in the DrivePool (E:\). I'd like to sort this list so I can get a list of files WITHOUT the attributes I listed above, which I've confirmed that I can copy to another location and they'll behave normally. 

    - This might not be possible, but once I get the files I can off the drive, I'd like to try using some sort of recovery software to recover the original files I overwrote. I know there's a small chance, and none of the data is extremely important, but if it works it might save me a bunch of hours re-ripping CDs and DVDs, and re-downloading various software. Any suggestions?

    Thanks again for the help, Shane. :)
  • Resident Guru
    Maybe I'm having a Monday (despite it being a Friday), but AL, APL, APLI?

    (and ouch, re overwriting with the tombstones - re software, perhaps recuva?)
  • I'm not a file attribute guru, but "dir /?" tells me that L is a "reparse point" which led me to thinking about the tombstone files. I could be way off, and hopefully I am, but it's the only thing that makes sense. 

    Thanks for the mention of recuva, as soon as I manage to get all my "real" data off the thing safely I'm going to give it a shot. In the meantime, no more writing to that disk!
  • edited September 2012 Resident Guru
    It's a bit kludgy, requires the physical drives to have drive letters within the range d-z, and doesn't work on files with paths larger than 255 characters (blame Microsoft for that), but here's a command line that will attempt to take Administrators ownership of every single folder and file in the pool at the physical drive level and - the important bit - dump a report of any failures to dpworktemp.txt

    del dpworktemp.txt & cls & for %a in (d e f g h i j k l m n o p q r s t u v w x y z) do dir /ad /b "%a:\poolpart.*" && dir /ad /b "%a:\poolpart.*" >dplist.temp && for /f %b in (dplist.temp) do takeown /f "%a:\%b" /a /r /d y | findstr /b /v "SUCCESS:" | findstr "." >>dpworktemp.txt

    Usage: run a command prompt (cmd.exe) on the server and paste the above command. To exclude the pool drive itself, remove the pool drive's letter from the set. To have individual reports for each drive, replace dpworktemp.txt with dpwork-%a. If creating a batch file from which to run this command, remember to replace occurrences %a with %%a and %b with %%b and be careful of the working directory.

    EDITED: added note about how to exclude pool drive and how to have individual reports for each drive.
  • edited September 2012 Member
    If I didn't want to run it against all drives, could I just do:

    del dpworktemp.txt & cls & for %a in (k) do dir /ad /b "%a:\poolpart.*" && dir /ad /b "%a:\poolpart.*" >dplist.temp && for /f %b in (dplist.temp) do takeown /f "%a:\%b" /a /r /d y | findstr /b /v "SUCCESS:" | findstr "." >>dpworktemp.txt
  • Resident Guru
    Oh, right. The "P" is still throwing me, though?
  • Resident Guru
    Yes, to run it against one drive, just have only that drive's letter instead of the entire range.

    Or if you wanted to run it against all drives but have a separate report file for each drive, replace dpworktemp.txt with dpwork-%a.txt
  • Super cool! I'll try it out here in a bit.
  • Resident Guru
    Oh! Crumbs. Remove your pool drive's letter itself from the range.

    If you run it against the pool drive itself, in theory it would pass the command on to the drives in the pool and you wouldn't need to run it against the physical drives that form the pool, but (a) I don't know what it will return if it gets different results for the same file on different drives if using duplication and (b) the idea is to directly check the physical drives.
  • Resident Guru
    (or you could leave your pool drive's letter in, and compare it to what you get for the physical drives...)
  • I was going to exclude the pool drive, just to keep things simple. 

    I discovered that if I cut/paste a dir, it'll copy everything over it can and allow me to skip the affected files, which is a good way to (a) get the data off the drive and (b) get a list of files affected. From there I'll generate a list of files that are on the drive but not in the drive pool, and then run your script to see if it works for any of them. If not, it's off to recovery software I go. 

    Luckily, the most important thing on the drive (the pictures folder) is backed up elsewhere and doesn't seem to be affected. 

  • So I went through and confirmed that all my pictures and photos were intact, and they are! My software share suffered some losses, but it was mostly crap I needed to delete anyway (why did I keep every beta and final release of xbmc exes for the last two years or so?). 

    I decide to see how much space the videos folder on the "broken" drive is taking up, as I want to copy as much as possible to the pool and didn't want to max out my space. For some reason Explorer is reporting that my videos folder, on one drive, is 7.22tb. :O

    (I'm sure it's some weird pointer/tombstone/bizarre issue, but man what a number!)
Sign In or Register to comment.