Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

This is a harder one to ask since I don't really have a clear picture of what I'm asking.

But, in a plain vanilla install of Windows Server 2012 (with only Web Server role/features enabled), installing SQL Server 2012 on top of it is taking over drive's (i.e. I get the "Access Denied" message when trying to open them up through explorer).

I have 3 drive's, C, D and E. During the installation of SQL Server 2012, I specify to install the core files to C:\Program Files... (i.e. the default destination), the temp database and tempdb log to D:\ (root) and the user databases and user db logs to E:\ (root). Before install, I can access the drives as expected but after the SQL Server 2012 installation completes I can no longer access the drives. i.e. Can't open them through explorer and the usage (space used) bar indicator doesn't display either.

Does anyone know what the cause of this is? Is it because I'm specifying installs to the root's of D and E (C still operates normally)? Is it something with SQL Server 2012 security? The install was done through an Admin account and I'm going back and trying to access the drive's through an Admin account.

It doesn't inhibit the actual usage of the database or creating new databases, as everything seems to function properly, it just bugs me that this is happening and don't want to use this for a production web machine (used just for IIS 8 and SQL Server) until I at least get a better understanding of this.

Any clarification is greatly appreciated.

share|improve this question
3  
You should never put data or log files in the root of a drive, IMHO. Aren't these explicitly protected places in modern versions of Windows? –  Aaron Bertrand Sep 26 '12 at 15:14
1  
Well, not sure why this didn't come up in my googling last night (I was most likely too tired) but this does seem to be related to specifiying the root: connect.microsoft.com/SQLServer/feedback/details/722545/… -- still would appreciate confirmation and any more insight offered here. Apologies for what appears to be an already answered question. –  Kevin Sep 26 '12 at 15:15
    
@AaronBertrand You could very well be right. My admin type experience with SQL Server is minimal. For some reason I was just thinking it'd be a cleaner setup to have those files on the root of those drives since I was dedicating the use of those drives to just those purposes. –  Kevin Sep 26 '12 at 15:18
2  
I can see how that would be simpler, but I've always used a subfolder. Other than the OS restrictions (and cases where the drive is used for other things, or multiple instances) I don't really have any other good reason for it. –  Aaron Bertrand Sep 26 '12 at 15:20
    
The link looks like your issue Kevin, but OS should prompt if you try to access one of the locked-down ACLs, and then you have to confirm your giving yourself access to it. Same with Server '08. You don't see the volume at all so as to be able to open it and confirm the perm elevation when prompted? –  Eric Higgins Sep 26 '12 at 16:33

1 Answer 1

up vote 2 down vote accepted

Oops... should mark this as answered.

The issue simply was specifying the root of the drive. Don't do that.

When specifying a folder in that drive, all is well.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.