SQL Server FCI installation with Mount Point permissions issues

Question

Please help me get past this installation issue.

I am trying to install a SQL Server 2016 (SP1 slipstreamed) Failover Cluster Instance (FCI) on two Windows Server 2012 R2 VMs.

I have 3 cluster disks.

• Data drive: E:\
• Log mount point: E:\MSSQL\Log\L1
• Tempdb mount point: E:\MSSQL\Data\Tempdb1

I first attempted to install directly to these root directories. After failing, I created subdirectories to install to. The service account and myself are local admins to the VMs and I explicitly granted full control on each of the subdirectories. Finally, I tried to ignore the mount points, for now, and just install to a subdirectory on E:. All attempts failed with the below error.

Detailed results: Feature: Database Engine Services Status: Failed: see logs for details Reason for failure: An error occurred during the setup process of the feature. Next Step: Use the following information to resolve the error, uninstall this feature, and then run the setup process again. Component name:
SQL Server Database Engine Services Instance Features Component error code: 0x84CF0004 Error description: While updating permission setting for folder 'E:\MSSQL\Data\TempDB1\System Volume Information' the permission setting update failed for file 'E:\MSSQL\Data\TempDB1\System Volume Information\ResumeKeyFilter.Store'. The folder permission setting were supposed to be set to 'D:P(A;OICI;FA;;;BA)(A;OICI;FA;;;SY)(A;OICI;FA;;;CO)(A;OICI;FA;;;S-1-5-80-419818685-2113908795-3893829424-1849583840-1690709397)'. Error help link:
http://go.microsoft.com/fwlink?LinkId=20476&ProdName=Microsoft+SQL+Server&EvtSrc=setup.rll&EvtID=50000&ProdVer=13.0.4001.0&EvtType=0x88792597%400xBB814387&EvtType=0x88792597%400xBB814387

Below is an anonymized version of the config file being used for install.

;SQL Server 2016 Configuration File
[OPTIONS]

ACTION="InstallFailoverCluster"
SUPPRESSPRIVACYSTATEMENTNOTICE="False"
IACCEPTROPENLICENSETERMS="False"
IAcceptSQLServerLicenseTerms="True"
ENU="True"
QUIET="False"
QUIETSIMPLE="True"
UpdateEnabled="True"
USEMICROSOFTUPDATE="False"
FEATURES=SQLENGINE,REPLICATION,FULLTEXT,DQ,CONN,BC,SDK,SNAC_SDK
UpdateSource="MU"
HELP="False"
INDICATEPROGRESS="True"
X86="False"
INSTANCENAME="InstName"
INSTALLSHAREDDIR="C:\Program Files\Microsoft SQL Server"
INSTALLSHAREDWOWDIR="C:\Program Files (x86)\Microsoft SQL Server"
INSTANCEID="InstName"
INSTANCEDIR="C:\Program Files\Microsoft SQL Server"
FAILOVERCLUSTERDISKS="Cluster Disk 7"
FAILOVERCLUSTERGROUP="SQL Server (InstName)"
FAILOVERCLUSTERIPADDRESSES="IPv4;10.10.10.17;Cluster Network 2;255.255.255.0"
FAILOVERCLUSTERNETWORKNAME="abc-123-IN"
AGTSVCACCOUNT="DOMAIN\sqlsvc-abc-123"
COMMFABRICPORT="0"
COMMFABRICNETWORKLEVEL="0"
COMMFABRICENCRYPTION="0"
MATRIXCMBRICKCOMMPORT="0"
FILESTREAMLEVEL="0"
SQLCOLLATION="SQL_Latin1_General_CP1_CI_AS"
SQLSVCACCOUNT="DOMAIN\sqlsvc-abc-123"
SQLSVCINSTANTFILEINIT="True"
SQLSYSADMINACCOUNTS="DOMAIN\AdminGroup"
SECURITYMODE="SQL"
SQLTEMPDBFILECOUNT="8"
SQLTEMPDBFILESIZE="8"
SQLTEMPDBFILEGROWTH="64"
SQLTEMPDBLOGFILESIZE="1024"
SQLTEMPDBLOGFILEGROWTH="128"
INSTALLSQLDATADIR="E:"
SQLBACKUPDIR="E:\MSSQL\Backup"
SQLUSERDBDIR="E:\MSSQL\Data"
SQLUSERDBLOGDIR="E:\MSSQL\Log"
SQLTEMPDBDIR="E:\MSSQL\Data"
SQLTEMPDBLOGDIR="E:\MSSQL\Data"
FTSVCACCOUNT="NT Service\MSSQLFDLauncher$InstName"

Answer 1

You may need to set permissions on the mount point volume instead of at a folder level. I suspect this is the issue you're running into.

From Guidelines for Setting SQL Permissions on Mount Point Folders (highlighting is Microsoft's):

Gotchas

Unfortunately, it is still possible to set/view permissions on the mount-point root folder via Windows Explorer, which can lead to unexpected results because the permissions of the mount-point root folder may seem valid and you can see “proper” inherited permissions, however these are not the permissions applied to the mounted volume.

• https://connect.microsoft.com/SQLServer/feedback/details/569895/installation-of-sql-server-2008-r2-on-mount-points-fails

Guidelines

1. It is recommended that you do not place any files directly in the mount-point root folder. This will make permissions management much simpler, because the tendency is to always check the folder permissions, which in this case is misleading. Instead, create a subfolder under the mount-point root folder, and set the proper permissions to that subfolder. Since the subfolder is a regular folder, the folder permissions you observe and set are indeed the permissions being applied. So using the previous example, you would want to create a new folder: D:\FolderForVol3**SubfolderXYZ**. Now, set your folder permissions against that new SubfolderXYZ folder as you normally would.
2. If you absolutely must place items directly in the mount-point root folder (Not the recommend approach), then you will need to set volume permissions, not folder permissions. Recall, that this is because the mount-point root folder permissions are not the permissions which will actually get set on the mounted volume (because the mount-point root folder is not a real folder). You can set volume permissions as follows:
   • Start->run->diskmgmt.msc (View the properties of a volume http://technet.microsoft.com/en-us/library/cc740097.aspx )
   • Select the volume->Properties->Security tab
3. If you are adding a new folder for SQL to use, be aware of the required permissions for SQL access:
   • Beginning with SQL Server 2012 permissions are assigned to the per-service SID for each of its services. http://msdn.microsoft.com/en-us/library/jj219062.aspx
   • Configure Windows Service Accounts and Permissions http://msdn.microsoft.com/en-us/library/ms143504.aspx

The way I had to solve this was by using the cacls.exe utility. Detailed instructions for it can be found here. I suspect your command to grant full permission to a user would be as follows:

cacls E:\MSSQL\Log\L1 /M /E /G YourUserName:F
cacls E:\MSSQL\Data\Tempdb1 /M /E /G YourUserName:F

You'll want to run this for your account and the SQL Server Service Accounts or group(s) as well.

Final note here, it is imperative that you include the /E flag, otherwise it will overwrite permissions on that path. This behavior carries additional side effects of ulcers and heavy drinking, so make sure you don't forget the edit flag when running this command.

---

Another option is to delete the drives and repartition them from scratch. They're still likely messed up from the original attempt at setting up security via Windows Explorer (e.g. check out the Gotcha clause from the first MS article).

In this case if you still want to write to the root folder on the mount path, you'll want to use the cacls utility. I would also suggest setting up three sub folders on E:\ such as Data, Logs, and TempDB and then install everything to the sub folders. Don't nest the mount points into a directory you'll install files to.

Answer 2

Microsoft SQL Server 2014 Setup: Failover Cluster Installation Setup

The Following Error Has Occurred:

Updating Permission Setting For file G:\System Volume Information\ResumeKeyFilter.Store failed.
The File Permission settings were supposed to be set to D:P(A;OICI;FA;;;BA)(A;OICI;FA;;;SY)(A;OICI;FA;;;CO)(A;OCICI;FA;;;S-1-5-80-3880718306-383280129-1677859214-2598158968-1052248003)

Resolved (Work Around)

First to view this hidden folder (System Volume Information) click on view tab and select Hidden Items and also go to options tab click on view tab and unselect Hide Protected Operating System File (Recommended).

To resolve issue I go to G:\System Volume Information\ folder and right click on file ResumeKeyFilter.Store click on properties and in security tab add your installation user, in my case I'm using domain user called grid and add this user for permission.

Answer 3

I had to install sql server 2019 on a windows server 2022 box for some connectivity testing and troubleshooting

so it is a temporary machine, if it was not I would have gone done the lines of the detailed answer by John Eisbrener

I had the same problems with drives, but instead of trying to solve it I just created folders on the c drive i.e. sqldata, sqllogs, etc and installed sql server using those drives instead.

then, after the installation, I went back to the H: and G: and I: drives ( these letter are in my new server in my case) and made sure they were formatted using NTFS, created the folders (sqldata or sqllogs these are the names I use for the folder where I put sql data files etc) respectively to each of the drives,

then restored a backup of a template database to my new sql server server using the c: drives - making sure I had enough disk space for that.

restored fine. then I did the magic (not so clever, but what worked out for me):

first detach the database:

USE [master]
GO
ALTER DATABASE [MY_DATABASE_Template] 
SET  SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
USE [master]
GO
EXEC master.dbo.sp_detach_db @dbname = N'MY_DATABASE_Template'
GO

then move the files to their respective places (after creating the folders under the respective drives, and copying the permissions from the original sql server folder to these ones - but this may or may not be necessary)

then attach the database with the files in their originally intended places:

USE [master]
GO
CREATE DATABASE [MY_DATABASE_Template] ON 
( FILENAME = N'G:\SQLDATA\MY_DATABASE_Radhe_Shyam_.mdf' ),
( FILENAME = N'I:\SQLLOGS\MY_DATABASE_Radhe_Shyam__Logs.ldf' ),
( FILENAME = N'H:\SQLDOCS\MY_DATABASE_Radhe_Shyam__ChangeLog.ndf' ),
( FILENAME = N'H:\SQLDOCS\MY_DATABASE_Radhe_Shyam__Docs.ndf' )
 FOR ATTACH
GO

Last but not least (I left all the security both inside the my_database, my_server and all of the folders - and these need to be addressed) but you need to make sure all the logins from wherever that database backup came from are in line with the users inside this database i.e. no orphaned users, no user left behind.

this worked for me, but sometimes you need to do a bit extra:

EXEC sp_change_users_login 'Auto_Fix', 'My_database_template'

Hope this gets a DBA off the stress I was, as it is not a solution, but a worked out that worked for me. Sometimes you depend on infrastructure and the guys are not around to help for instance.