It looks like you're new here. If you want to get involved, click one of these buttons!
In order to better support our growing community we've set up a new more powerful forum.
The new forum is at: http://community.covecube.com
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,
Comments
You should have been able to recover by manually resetting the permissions worst case as the data would have still been on on the drives in the hidden folders.
If you have not touched the data drives you can still recover.
I have 22 drives, so going through them individually would be quite the task. Is there another, quicker way to fix permissions so I can access my files again?
Thats how I got around the 3874 access issues but there might be better ways of fixing it.
Well.. I had hoped that the data wasn't gone, but just had a chance to go and look through the hidden folders on the volumes and it did delete the files, so I guess I'm back to square one on that front. Still not sure what happened..
On the current load where I am able to access my files - I have SBS Essentials running 3929.. All of my shares are accessible (minus the one that got deleted..) I tried loading the system on an alternate OS drive - SSD - and by the time I had everything loaded up 3940 was the only binary available.. I installed it on the clean SSD OS load and went through the "foreign disk" validation.. none of the shares were showing up - so I rebooted the system.. still none of the shares showed up - at that point I probably should have just quit and submitted the logs and went back to my original OS drive, but I couldn't help "poking it with a stick".. I had seen the comment from Sean and thought that might correct the issue - apparently not in my case ..
Not really sure what happened between 3929 and 3940 but apparently it wasn't very nice to me.. I've got a backup of that 400GB offsite, but it is going to take a while to regenerate it.. Of course it would be a lot faster - or I assume it would be - if I was able to switch back to the SSD OS drive, but I still can't get the rest of the shares to mount on that load..
Hmmm.. just rebooted off the origianl OS load and tried to recreate the share and I am getting an access denied error.. not sure what would cause that, I checked on all the pooled drives and the share.1 folders are gone from all the drives..
@Alex I submitted a bug report through the wiki.. Not sure what is causing the problems I am running into.. On the separate OS load I can't get the pool to mount completely.. Same OS, same updates, same version of DP.. Initial performance of the system running on the SSD is a lot better than this standard SATA drive, with the exception that I can't get the pool running of couse
My output is up at http://pastebin.com/Q6fAmEhr
Here's the result from the C:\ServerPool\ServerFolders directory: http://pastebin.com/yYBzvNLX
I don't think 3959 included a fix to prevent it from happening it just fixed the issue when you reapplied the permissions when they got messed up. But I could be wrong.