Backup Temp Folder Permissions

Starting with v8.5, SQL Backup Master tightens the NTFS permissions on its working backup folder and isolates each job's intermediate files in a per-job sub-directory. This article explains the new model, the configurations that opt out of it, and what you may need to do if you've customized the SQL Backup Master service account.

What changed

SQL Backup Master uses a temp folder – by default C:\ProgramData\Key Metric Software\SQL Backup Master\bak\ – as the working directory for backup file processing. The folder holds .bak files written by SQL Server, intermediate compressed and encrypted artifacts produced by SQL Backup Master, and (during recovery) downloaded backup files awaiting restore.

In earlier versions, the installer granted Full Control on this folder to all local users. This made it easy for SQL Server – running under whichever Windows account it happened to use – to read and write files in the folder without per-environment tuning. The trade-off was that any local user with logon access to the SQL Backup Master host could also read the .bak files, and because the .bak file format is openly documented, that effectively meant they could read every row in every backed-up database.

v8.5 changes this in two ways:

• The installer now sets the base temp folder's ACL to SYSTEM:F and Administrators:F only, with inheritance protection on. Members of Users no longer have any access. This applies on fresh installs and on upgrades.
• At job-run time, SQL Backup Master creates a GUID-named sub-directory under the base temp folder for each backup or recovery, scoped to that one operation. The sub-directory inherits the tight base ACL and additionally grants read or write access to the specific SQL Server service account that needs it (plus the per-job impersonation account, when configured). When the operation completes, the sub-directory is removed entirely – ACEs and all.

The net effect: a backup file lives in a directory readable only by SYSTEM, Administrators, and the specific SQL Server service account that needs to read it – for as long as it takes the backup or recovery to finish, and not a moment longer.

Who needs to read this

You probably need to take action if any of the following applies to your installation:

• You've configured the SQL Backup Master Windows service to run under a non-default identity (a domain account, a managed service account, or a group-managed service account). See the Non-default service identity section below.
• You're upgrading and you've customized the temp folder path, or you depend on local non-administrator processes being able to read files in the temp folder. See the Opting out section below.

If you run SQL Backup Master with default settings under the default LocalSystem service identity, no action is required. The upgrade tightens permissions automatically and the new per-job scopes work without configuration.

When SQL Backup Master manages permissions

The new permission management activates when all of the following are true:

• The configured temp folder is the default path: C:\ProgramData\Key Metric Software\SQL Backup Master\bak\.
• The local compression staging folder, if enabled, is also the default path.
• No alternate temp folder is configured (no Samba / Linux SQL Server scenario).
• No authentication credentials are set on the temp folder (no UNC share with credentials).
• The SQL Server instance being backed up or restored to is local.

Any deviation from this list opts the configuration out of SBM-managed permissions entirely. There is no partial mode – either SQL Backup Master owns the temp folder permissions, or you do.

Opting out: when SQL Backup Master leaves permissions alone

If you've customized any of the settings listed above, SQL Backup Master treats the configuration as customer-managed and behaves exactly as it did in earlier versions. Specifically:

• No per-job GUID sub-directory is created. Files land directly in the configured temp folder, just like before.
• No NTFS permissions are changed on the configured folder, sub-directories within it, or files placed in it. Whatever ACLs you've configured remain in place untouched.
• The recovery flow continues to apply its legacy "Authenticated Users: Read" ACE to each downloaded .bak file, the same way it did in earlier versions – ensuring backward compatibility for setups that rely on this ACE to bridge custom folder permissions to SQL Server.

The most common reasons for opting out:

• You moved the temp folder for disk space reasons. Customers often relocate the temp folder to a dedicated drive with more space. This is a fully supported configuration; v8.5 just doesn't apply its managed-permissions model on top of your customization.
• You're backing up SQL Server on Linux through a Samba share. The share's permissions are managed on the Linux side. See the SQL Server on Linux article for the full configuration.
• You're backing up a remote Windows SQL Server through a UNC share with credentials. The share is hosted on the remote machine and its permissions are governed there.
• The SQL Server instance is remote. A local ACL granting access to a remote SQL service account isn't meaningful – the file is read over SMB on the remote side.

The user interface flags customized temp folder configurations with a "Manual permissions required" hint adjacent to the temp folder field in the backup job settings. The hint links back to this article.

Non-default service identity

If you've configured the SQL Backup Master Windows service to run under an identity other than the default LocalSystem, the tightened base ACL will prevent the service from creating its per-job sub-directories – because the new ACL grants Full Control only to SYSTEM and Administrators, and your service identity is presumably neither.

Grant the service identity Full Control on the base temp folder, with object-inherit and container-inherit flags so the ACE propagates to the per-job sub-directories that SQL Backup Master creates inside it. From an elevated command prompt:

icacls "C:\ProgramData\Key Metric Software\SQL Backup Master\bak" /grant "DOMAIN\sbm-service":(OI)(CI)F
                                    

The same command works for all common service identity types, with the account spelled appropriately:

• Domain user account:

  icacls "C:\ProgramData\Key Metric Software\SQL Backup Master\bak" /grant "CONTOSO\sbm-svc":(OI)(CI)F
                                              

• Local user account:

  icacls "C:\ProgramData\Key Metric Software\SQL Backup Master\bak" /grant "SBM-HOST\sbm-svc":(OI)(CI)F
                                              

• Managed service account (MSA) or group-managed service account (gMSA):

  icacls "C:\ProgramData\Key Metric Software\SQL Backup Master\bak" /grant "CONTOSO\sbm-gmsa$":(OI)(CI)F
                                              

  Note the trailing $ on the gMSA account name – this is part of the account spelling, not a placeholder.

At every service start, SQL Backup Master writes a small probe file to its temp folder and then immediately deletes it. If that write fails, the service logs an Error in the Windows Event Log with the current service identity and the exact icacls command (templated to your environment) to remediate. Look in the Windows Event Log under Applications and Services Logs → SQL Backup Master for entries from the TempFolderWriteProbe source if backups start failing unexpectedly after a service identity change.

Customer-visible behavior changes

The following are the only user-visible differences in v8.5:

• On installations using the default temp folder, in-flight backup files now live inside a GUID-named sub-directory (e.g. \bak\7f3a9c2e4b1d4e8fa2c5d7b8e9f0a1b2\database.bak) for the duration of the operation, rather than at the root of the \bak\ folder. Anything that watches the temp folder for file activity needs to be aware of the additional directory level. The files are removed (along with their sub-directory) when the operation completes.
• Non-administrator local users no longer have read access to .bak files in the default temp folder. If you have tooling that runs as a non-administrator and needs read access to those files, either move the temp folder to a customer-managed path (which opts out of the managed model) or grant that account read access to the base folder explicitly – with the understanding that doing so partially undoes the v8.5 hardening.
• A startup orphan-cleanup pass removes any abandoned sub-directories from previous service lifetimes (crash, kill, power loss). This runs once at service start and then hourly thereafter; you can ignore the resulting Info entries unless they appear in unusual volumes.

Troubleshooting

Backup jobs fail with "Access is denied" creating the temp directory. Most likely you've changed the SQL Backup Master service identity from LocalSystem to a non-administrator account without granting that account access to the base temp folder. Run the icacls command above with the correct account name. Check the Windows Event Log for the templated remediation message the service logs on startup.

Backup jobs fail with "Could not resolve the SQL Server service account." This is the managed-mode equivalent of "we couldn't figure out which Windows identity to grant access to." It's rare in practice – SQL Backup Master tries multiple resolution strategies, including a fallback that queries the local Service Control Manager. The most common cause is an unusual SQL Server configuration that doesn't register with the local SCM in the expected way. If you hit this on a configuration you believe should work, please reach out to support with the job log; we'd like to add the case to our test matrix.

Recovery fails with a permissions error after upgrade. The legacy SetFileReadableByAuthenticatedUsers behavior is preserved for customized temp folders. If you're on a customized temp folder and recovery worked before but fails after upgrade, the cause is likely something other than the v8.5 changes – check the job log for the actual SQL Server error and address that first.

Disk fills with abandoned GUID sub-directories. The hourly orphan-cleanup pass should prevent this, but if you observe it, please reach out to support with the contents of a sample sub-directory. The sweeper logs an Info entry for each scope it reaps and a Warn entry for any it couldn't (typically because a file handle is held open).

Security notes

The default configuration protects against:

• A non-administrator local user reading .bak files at the OS level. Prior to v8.5, the default temp folder ACL allowed any local user to read backup contents directly; v8.5 limits this to SYSTEM, Administrators, and the specific SQL Server service account during each operation.
• A non-administrator process opportunistically reading files left behind by an interrupted backup or recovery. The per-job scope is removed (or, at worst, swept up by the orphan-cleanup pass) so the window in which any file is accessible is bounded.

The default configuration does not protect against:

• A local administrator. Administrators retain Full Control by design – an administrator can read anything on the host.
• Off-host disclosure of backup files. The hardening applies to NTFS permissions on the SQL Backup Master host; protecting backup contents in transit to a destination, and at rest on that destination, requires backup encryption (configured per job).
• Configurations that opt out via customization. If you've moved the temp folder, or are using a Samba share or remote SQL Server, the v8.5 model doesn't apply – you're managing permissions on whichever filesystem holds your backup files.

Getting help

If you encounter unexpected permission errors after upgrading to v8.5, or you're unsure which configuration category your installation falls into, please reach out to SQL Backup Master support with a description of how SQL Backup Master is deployed (default or customized temp folder, default LocalSystem or non-default service identity, local or remote SQL Server, any Samba / UNC share involvement) and we'll help you sort it out.