Operating System Error 1326 in SQL Server: Cannot Open Backup Device

Operating system error 1326 means authentication failed while SQL Server tried to open the backup destination. In this 2017 case, SQL Server ran on a workgroup computer and the backup share was on a domain server. The boundary between those identities mattered.

Start With the Error and the Destination

The backup task reported this type of error. The example uses a neutral server and file name.

Cannot open backup device '\\BackupServer\SqlBackups\ExampleDb.bak'.
Operating system error 1326
(Logon failure: unknown user name or bad password.).
BACKUP DATABASE is terminating abnormally.

Keep the exact operating system error. A logon failure differs from a missing path and from an access denied error after a successful logon. A password typo is one cause, but the account context and the trust relationship also need a check.

Compare the Error Codes

Four codes show up in backup failures to a share, and each points to a different layer. The first block triggers two of them in a test database. The second prints the Windows text for four codes.

DECLARE @db sysname = DB_NAME();
BACKUP DATABASE @db TO DISK = N'Z:\Backups\Test.bak';
BACKUP DATABASE @db TO DISK = N'\\localhost\NoSuchShare\Test.bak';

1326, 67, 5, 3 | ForEach-Object { '{0}: {1}' -f $_, ((net helpmsg $_) -join ' ').Trim() }

A missing drive returned operating system error 3. A share name that does not exist returned error 67. Neither looks like a logon problem. Error 1326 reads The user name or password is incorrect, and error 5 reads Access is denied. Error 5 means the logon worked and the permission is missing. Error 1326 means the logon itself failed.

Identify the Process That Writes the Backup

For a BACKUP command, the Database Engine service writes the file. A job history line that shows the SQL Server Agent account does not mean that account opens the destination. It is easy to blur those two identities.

This query lists the services of the instance and their accounts. It needs VIEW SERVER STATE on SQL Server 2019 and earlier. On SQL Server 2022 and later it needs VIEW SERVER SECURITY STATE.

SELECT servicename, service_account, status_desc
FROM sys.dm_server_services
ORDER BY servicename;

My Database Engine runs as NT Service\MSSQL$SQLDEV, and SQL Server Agent has its own account and is stopped. Those are the identities the destination sees. For a package or job with extra file copy steps, check those steps separately, because their identity can differ.

Check Authentication and Access Separately

1. Confirm the UNC path, the share server and the account that the Database Engine uses on the network.
2. Ask the Windows administrator to inspect the failed logon on the destination server. In a workgroup to domain setup, a local identity cannot authenticate as a domain identity.
3. After authentication works, verify the share and file system permissions for that identity.
4. Use a UNC destination such as \\BackupServer\SqlBackups\ExampleDb.bak. A drive that you mapped in your desktop session is not visible to a Windows service.

You can also ask the engine, which uses its own identity. This function lists a folder as the service and prints the operating system error when it fails.

SELECT full_filesystem_path, is_directory
FROM sys.dm_os_enumerate_filesystem(N'\\localhost\NoSuchShare\', N'*');

On my PC it printed error 0x80070043, the network name cannot be found, and returned no rows. On a real share that rejects the service identity, expect 0x8007052E, the hex form of error 1326. This test needs no backup and no password.

Keep Credentials Out of the Workaround

The original case used an authenticated drive mapping inside the service context. I would not use its embedded password and xp_cmdshell commands as a routine fix. They expose credentials and depend on a session mapping. On my instance xp_cmdshell is off, the safer default.

Have the administrators of both systems resolve the service identity and the network access. Use SQL Server Configuration Manager for a planned change of the service account. Do not broadly change credentials or open the share to everyone to clear the error.

When the access works, confirm that the backup completes and add a restore test to your validation. Browsing the share as yourself does not prove that the backup service can write to it.

A successful desktop login is not proof of backup access, it is a different security context.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.