Error 1326 Logon Failure when attempting to backup to remote server RRS feed

  • Question

  • Hi all:


    We currently have a production server (prodserver) and backup server (backupserver) in the same domain, and I am attempting to backup dbs from the production box on to the backup box using the following:


    backup database db to disk = '\\backupserver\e$\backup\db.bak' with init


    when executing from SSMS, I receive the following error:


    Msg 3201, Level 16, State 1, Line 1

    Cannot open backup device '\\backupserver\e$\backup\db.bak' Operating system error 1326 (Logon failure: unknown user name or bad password)


    Here's where the issue lies for me:

    • Both the production and backup box are running services under the same domain accounts, let's call it "domain\sqlagent"
    • domain\sqlagent has domain admin rights on backupserver and prodserver
    • I can login to both the production and backup servers using the domain account, map drives, hit administrative shares, drag and drop files, etc between the servers
    • If I use xp_cmdshell to try and simply move a file between prodserver and backupserver, I receive the above error as well.  However, if I open an cmd window and execute the move command from DOS, it will successfully move.
    • There is a development server on the domain as well (devserver) using domain\sqlagent to run the service accounts, and I can successfully backup databases from dev to prod, dev to backup, backup to dev, backup to prod, prod to dev, but NOT prod to backup
    • Finally, if I create a maintenance plan in SSMS, I cannot create a connection to the backup server (error reads the connection may not be configured correctly or you may not have the right permissions on this connection)
    • The backup server was changed to a different domain (domain2) before I arrived here, but has been switched back now, rebooted, service accounts changed via Configuration Manager, services restarted (and rebooted again for good measure).

    Does SSMS use a different security context to create the connections to remote servers?  From all my tests, the domain\sqlagent account has all the correct rights and is working OK.  Could this be a network issue?  The network admin and I have been banging our heads against a wall for the past couple of days, so if anyone has seen something like this, I'd appreciate any help. 





    Thursday, October 18, 2007 5:31 PM

All replies

  • Well, the SQL Agent account isn´t even touched if you are doing something in SSMS. If you are logged in with SQL Server credentials, you will get the context of the SQL Server account. If that one does not have the appropiate permissions, you will get the error messages mentioned above. If you are using Windows authentication you are using your current context. Starting the SQL Server Agent jobs doing the same thing, the SQL Server Agent Account is used for impersonation, if that one is only priviledged on the local server, you won´t get any access to network servers.

    Jens K. Suessmeyer


    Thursday, October 18, 2007 9:13 PM
  • Hi Jens:


    Thanks for your reply.  I am logging in with Windows Authentication, using the same domain account that the SQL server account is running under.  That particular account has appropriate network privileges - it is part of the domain admin group.


    I am wondering if the fact that the backup server was removed and then re-joined to the current domain has something to do with it - i.e. if SQL Server on the production box is holding on to some sort of security GUID to identify the backup server which has changed due to the domain change and re-join?  The services on the production box have not been restarted since the domain rejoin of the backup server; but this is getting out of my area of expertise.



    Thursday, October 18, 2007 10:15 PM
  • When you try to acces a network file, and use '$', you need to have administrative privileges on that volume. Try creating a network sharing
    in volume "E:\backup" on \\backupserver, then access '\\backupserver\backup\db.bak'. Don´t forget to add the privileges to the sql service user account on that volume.
    Friday, September 18, 2009 7:57 PM