SQL Server Home
Installation of SQL Server 2008 R2 on Mount Points fails
6/23/2010 1:13:48 AM
User(s) can reproduce this bug
When I try to install SQL Server 2008 R2 x64 on Windows Server 2008 R2 with the use of Mount Points for the data directory the installation fails.
The Error shows up in the Errorlog:
2010-06-22 18:33:12.49 spid8s Clearing tempdb database.
2010-06-22 18:33:12.71 spid8s Error: 5123, Severity: 16, State: 1.
2010-06-22 18:33:12.71 spid8s CREATE FILE encountered operating system error 5(failed to retrieve text for this error. Reason: 15100) while attempting to open or create the physical file 'D:\Data\DBData\tempdb.mdf'.
2010-06-22 18:33:12.87 spid8s Error: 5123, Severity: 16, State: 1.
2010-06-22 18:33:12.87 spid8s CREATE FILE encountered operating system error 5(failed to retrieve text for this error. Reason: 15105) while attempting to open or create the physical file 'D:\Data\DBData\tempdb.mdf'.
2010-06-22 18:33:13.54 spid8s Error: 17204, Severity: 16, State: 1.
2010-06-22 18:33:13.54 spid8s FCB::Open failed: Could not open file D:\Data\DBData\tempdb.mdf for file number 1. OS error: 2(failed to retrieve text for this error. Reason: 15105).
2010-06-22 18:33:13.58 spid8s Error: 5120, Severity: 16, State: 101.
2010-06-22 18:33:13.58 spid8s Unable to open the physical file "D:\Data\DBData\tempdb.mdf". Operating system error 2: "2(failed to retrieve text for this error. Reason: 15105)".
2010-06-22 18:33:13.66 spid8s Error: 1802, Severity: 16, State: 4.
2010-06-22 18:33:13.66 spid8s CREATE DATABASE failed. Some file names listed could not be created. Check related errors.
2010-06-22 18:33:13.70 spid8s Could not create tempdb. You may not have enough disk space available. Free additional disk space by deleting other files on the tempdb drive and then restart SQL Server. Check for additional errors in the event log that may indicate why the tempdb files could not be initialized.
The Problem seems to be in the Permissions area, because when I add the installer user and the service user (Domain User) to the SQLServerMSSQLUser$server1$SQL2K8R2 local group, the installation is successful.
SQL Server 2008 R2 - Developer Edition
Windows Server 2008 R2
Operating System Language
Steps to Reproduce
1. Add a installer domain user to the local Administrators group
2. Login as installer user
3. Create 2 Mount Points for Data and Transaction Logs (D:\Data\DBData & D:\Data\TLog)
4. Start Setup and use these folder for the data files
5. Define D:\Data\DBData\TempDB for TempDB data and TLog files
6. Execute the setup: Setup fails
When adding the installer and the service account to the SQLServerMSSQLSUser Group the setup is successful.
See attached Errorlog
No Errors in Errorlog and successful installation
to post a comment.
Please enter a comment.
on 7/27/2011 at 8:12 AM
I can replicate this issue on a SQL Server 2008R2 installation via the GUI. Installation to the root of a mount point fails, yet to a first level directory within the mountpoint works fine.
on 5/18/2011 at 1:36 PM
This article gives a good description of the workaround(2) and the steps required to fix it as indicated by MS: http://getyouriton.blogspot.com/2009/08/serious-gotchas-with-mounted-drives-or.html
on 5/16/2011 at 9:21 PM
Prehaps an OS Modification "Fix"?
I would have really expected if the root mount drive has permissions that it would do the inherited permissions correctly to all subfolder mounted drives.
It is really frustrating to reapply permissions multiple times across the following:
M: [Root Mount Point]
M:\DATA\DB1 [Mount Point]
M:\DATA\DB1\INDEX [Mount Point]
M:\DATA\DB1\FILEGROUP1 [Mount Point]
M:\LOGS\DB1 [Mount Point]
This quickly moves into a long setup time - 4 seperate volume permissions need to be modified. Would be nice to just set at the root-mount point and have this flow through all the mount-points for new file creation.
Its not a database OS Bug fix, but a Windows OS Bug fix - or allow us an option to also change the "Default" volume permissions at the same time: prehaps a pop-up dialog if it detects mount-points?
Less clicks - faster config = less time to deploy and easier to manage.
on 8/31/2010 at 7:16 PM
The reported issue will not be addressed in a product change, but will be discussed in an upcoming Knowledgebase article, summarized below:
If the directory which hosts SQL server system database, such as tempdb, is a mount points to another volume, the setup may encouter failure if the mounted volume has not enough security permissions for SQL service accounts.
The reason for this problem is Windows security API does not propagate security settings from a mount point to the root settings of the volume it points. So SQL server service cannot be started due to lack off permissions.
Workaround 1: Using a sub directory under the mount points. For example, T:\mountX is a mount points of volume X. Then specify T:\mountX\data as the database directory will solve this issue.
Workaround 2: Add SQL server service account full control permissions to the volume, such as X, in disk management console.
on 7/27/2010 at 6:10 AM
I have exactly the same issue doing a SQL 2008 (not R2) install using Mount Points.
on 7/2/2010 at 10:42 AM
We have received your error report are investigating what could be the cause of the failure.
Lee - SQL Server
to post a workaround.
Please enter a workaround.
on 10/25/2011 at 4:19 PM
Working on min'm privileges for installations, I also came across same problem. A third work arround I found on another site, sorry it was a while ago and I don't remember it, was to make the service accounts local administrators on all nodes. I was so frustrated with the installation, I used all three. After the installation you can remove the service account from local administrators. Sounds very similar to elevation of the rightrs the installation account but the authority can be localised and reversed without much concern.
on 8/10/2011 at 9:52 AM
I got the same problem, I was trying to move tempdb and as everybody knows if tempdb files are not there. it will automatically create it.
However it was not happening, as it seems to be bug in win 2008.
For me issue was that while running alter database command suppose i had given path "E:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\tempdb" without any extension. My main concern was to create a file in tempdb folder, however i forget to give file name.
Window 2008 was not allowing to create a new file with name tempdb as per above path in MSSQL folder. So it means Win 2008 isnt able to differentiate between folder and files.
I am not sure it will work for others, however it worked for me.
Happy troubleshooting :)
on 7/9/2010 at 9:14 AM
I found a workaround for that: When I precreate the folders in which the SQL Server Instance should place his files, the installation completes successfully.
I think the problem is on the way, how the SQL Server setup assigns the permissions and then tries to create files in these folders, respectively under which account the service is started the first time.
© 2014 Microsoft