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. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am aware that SQL Server instances need write access not for my user account (which is in fact irrelevant to that service's context) but for the user account or security principal under which the SQL Server Service is running. (In my case NT Service\MSSQLSERVER)

Having done that, and having verified that when I create a new database in this folder, I can write to this folder, and that the database files created by this server instance are created with the user MSSQLSERVER, nevertheless, I still lack the ability to write to any folder on drive E, from the context of MS SQL, unless I also add "write" permissions for "Everyone", adding write access to the "MSSQLSERVER" is not enough.

There must be some other level of NTFS security involved here. It almost reminds me of a domain trust issue. This is on MS SQL Server 2012, running on Windows 8 Pro.

What do you do next, if adding the MSSQL account name found in the "Log On" tab of the service, does not work? It's frustrating, but I'm stuck with giving "Everyone" write access to this folder on drive E before any folder is writeable by SQL Server. Drive E in my case is a regular local hard drive, not a network folder. (I'm not dumb enough to try to run SQL on a network mounted drive.)

share|improve this question
I have a feeling it has something to do with OWNER RIGHTS – Warren P Jan 30 '13 at 20:55
Avoid granting permissions directly to the service account, or service SID. Instead, grant permissions to the container group (which I'm assuming is a local group in this scenario). What is the folder structure on the E drive? Do you need to set/reset permissions lower down in the hierarchy? – Jon Seigel Jan 30 '13 at 23:51

The actual problem is that the SYSTEM or other container group had not had the NTFS permissions set for the SQL db folder on the SQL data drive, in my case, 'E:\SQLDATA`

The root E:\ drive was not accessible, so a specific NTFS permission had to be created for the SQLDATA.

share|improve this answer

Your Answer


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.