0

When attempting to start the SQL Full-text Filter Daemon Launcher service through the SQL Server Configuration Manager, it attempts to launch, but then fails.

In the event log we get the following error message: "The SQL Full-text Filter Daemon Launcher (instancename) service failed to start due to the following error: Access is denied."

It is currently set in "Manual" start mode. And uses the default service account generated at installation, "NT Service\MSSQLFDLauncher$instancename". Named pipes is enabled.

This service was not installed as part of the original SQL Server installation, but done after.

This is a SQL Server 2016 Enterprise (13.0.5216.0) instance.

Improve this question
2
  • Did you use a slipstreamed version or update it after the fact? Have you taken a procmon to see if anything shows?
    – Sean Gallardy
    Commented Mar 4, 2019 at 22:37
  • @SeanGallardy it was not a slipstreamed install, but updated after the fact. I'll give procmon a try
    – SQL3D
    Commented Mar 5, 2019 at 19:38

1 Answer 1

Reset to default
0

After trial and error, I found that in my case:

The SQL Full-text Filter Daemon Launcher (MSSQLSERVER) service failed to start due to the following error: \r\nAccess is denied

Was due to installing MSSQL with the TEMPDB on a non default location:

$process = Start-Process -Wait -NoNewWindow -FilePath "C:\SQLServerISO\setup.exe" -ArgumentList "/Q",
"/ACTION=install",
"/SUPPRESSPRIVACYSTATEMENTNOTICE",
"/INSTANCEDIR=`"$systemDbDir`"",
"/INSTANCEID=MSSQLSERVER",
"/INSTANCENAME=MSSQLSERVER",
"/FEATURES=SQLENGINE,FullText",
"/INSTALLSQLDATADIR=`"$installDir`"",
"/SQLUSERDBDIR=`"$userDbDir`"",
"/SQLUSERDBLOGDIR=`"$userDbLogDir`"",
"/SQLSVCACCOUNT=`"NT AUTHORITY\System`"",
"/SQLSYSADMINACCOUNTS=`"BUILTIN\ADMINISTRATORS`"", 
"/TCPENABLED=1",
"/NPENABLED=0",
"/SQLTEMPDBDIR=`"$systemDbDir`"", # <---- THE PROBLEM IS THIS NOT BEING IN THE DEFAULT DIR!
"/SQLTEMPDBLOGDIR=`"$systemDbLogDir`"",
"/SQLBACKUPDIR=`"$backupDir`"",
"/UpdateEnabled=0",
"/IACCEPTSQLSERVERLICENSETERMS",
"/SQLSYSADMINACCOUNTS=ContainerAdministrator" -PassThru;

But rather and an actual access denied error, the root cause must be something else because even if granting full access to the FTS Daemon service to the TempDB path, and even changing the identity of the FTS Daemon to a local admin the issue persists.

Improve this answer
1
  • The problem turned out to be that "/INSTANCEDIR="$systemDbDir"" and "/SQLTEMPDBDIR="$systemDbDir"", had the same location (which makes no sense) yet I cannot figure out how that surfaced as an Access Denied Error when trying to start the FTS Daemon Service.
    – David
    Commented Feb 16 at 7:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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