Database backup to a network shared folder Error Operating system error 1265


  • Hi,

    I am trying to backup a database to a shared folder which is located in some other on the same network using SQL Server management studio. I get below error: 

    System.Data.SqlClient.SqlError: Cannot open backup device '\\SP2Server\SPBackup\SalesDb.bak'. Operating system error 1265(The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.). (Microsoft.SqlServer.Smo)

    I made the account that my sql server service is running as is a domain account and it has full access to the shared folder. In fact I gave full access to 'Everyone'. I could perform the backup on the same server (Server where SQL server is installed) easily. Issues only when backup to a network shared folder. I checked the user permission of the default backup folder of SQL Server (D:\DATABASE\MSSQL10.SQL2008\MSSQL\Backup) and noticed that a user SQLServerMSSQLUser$SP2Server$SQL2008 has read/write  permission on this backup folder. Since this user is not a domain user, I can't give permission for this user on my network shared folder.

    Please advise.




    Thursday, April 25, 2013 10:31 AM

All replies

  • Hello,

    Please read the following thread with similar issue:  

    Hope this helps.


    Alberto Morillo

    Thursday, April 25, 2013 11:19 AM
  • Hi,

    My interpretation of your problem is...

    1) When you run the backup, it runs under your credentials - not the domain account that starts sql server

    2) make sure you understand that when it comes to shared folders you need to take configure share AND NTFS permissions. Grant Change (Share) and Modify(NTFS) on the target backup server to your domain account and that should work.


    Friday, April 26, 2013 11:50 AM
  • This is incorrect.

    Backups executed from a query window, are executed as the service account.

    What is the service account ? There is where you should begin troubleshooting.

    Jeff Block t:@sqlDictum (

    Friday, April 26, 2013 8:30 PM
  • Hello Naush,

    How are you running the backup. If you turn on sql profiler and under management studio GUI (right click - tasks - backup) , you will see that the backup runs under your security credentials. If you script out the backup task and run it in a query window, it also runs under your credentials ( proof via sql profiler ).

    Running the backup under sql agent or ssis is another story.

    Monday, April 29, 2013 6:51 AM
  • This is also incorrect.

    Profile shows only what the SQL credentials are, not what is being used for interaction with the underlying OS. Point in case: if you were logged in with a non-domain account, sa for example.  There is no relationship between the sa account (or any sql server login) and a windows domain account.

    If you run process monitor or filemon from sysinternals and watch the backup/restore file thread, you will see that it is being executed by the sql service account (if the command is executed from SSMS or SQLCMD), or the agent account if coming from a job.

    I'd be happy to post the traces for you from both profiler and process mon, but that seem a little overboard.

    Jeff Block t:@sqlDictum (

    Wednesday, May 1, 2013 3:40 PM
  • funny, i didn't know it was so easy to impersonate as some other account. Anyway, I ran fsmgmt.msc on the target shared folder machine and it still shows my account as accessing the shared folder and not the service account.

    Friday, May 3, 2013 2:48 AM
  • Just to be sure, I spun up a fresh vm, installed SQL and ran again, service account is showing up. I also ran netmon just to ensure there wasn't something funky in there, and the packet capture shows the service account as expected. Are you using a proxy account ? It's possible to setup but very unusual for non-agent executions. Other than that I can't imagine how your setup would support this, it's counter to MS documentation.

    Transaction log backups: (ditto for the db backup article):

    "Ownership and permission problems on the backup device's physical file can interfere with a backup operation. SQL Server must be able to read and write to the device; the account under which the SQL Server service runs must have write permissions. "

     Log shipping TN, see the implication of the first few paragraph relative to backup and permissions:

    Jeff Block t:@sqlDictum (

    Friday, May 3, 2013 3:02 AM