April 6, 2011 at 12:05 pm
Not sure if this will help but I once ran itno something similar.
I changed the server name to it's ip address and the unc and is started working.
April 6, 2011 at 2:51 pm
Steve,
When i ran accessenum on the box, it did show me that the user i am logged in has read and write access to the shared folder.
April 7, 2011 at 12:22 pm
Can you run the "dir" job from Agent and have that work?
It's definitely a strange error. It's almost like you have some token or kereberos issue with the job.
If you manually run the backup, does that work?
April 7, 2011 at 12:51 pm
Have you tried relaxing the permissions for the share?
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
April 7, 2011 at 12:53 pm
Capture a Process Monitor trace on the destination server and check if the account requesting access on the share is showing up as anonymous. It could be an impersonation issue.
This posting is provided "AS IS" with no warranties, and confers no rights.
My Blog: TroubleshootingSQL
Twitter: @banerjeeamit
November 3, 2011 at 11:54 pm
January 11, 2012 at 3:10 pm
We're running into the same user. I made sure the following:
- running SQL 2008 SQL Agent as a Windows admin account called "SqlService"
- ensured that that account has full access to the UNC directory
- I can create a backup file to a local folder through the job
- it warns me on the manual backup file that it can't verify the UNC location
- I tried mapping the UNC to a drive letter without success (cannot find the path specified)
- I tried logging in as myself (a windows admin, sql server sysadmin) to backup to any network drive (cannot find the path specified)
Just don't know how to proceed from here. I can't get a directory in the job, as asked by Steve Jones.
January 12, 2012 at 5:00 am
October 5, 2012 at 2:37 pm
I'm having the same issue. My sqlservice and agent accounts have full access to the cifs. I can manually browse and create/delete folders while logged on as those accounts.
My backup maintenance plan is run by a SQL Server login, but does not complete a backup to the cifs. Fails with access denied.
November 1, 2012 at 2:41 pm
Check that there is no space on the end of the database name
November 1, 2012 at 3:32 pm
Bouncing the box worked for me. I believe it had something to do with SPN registration.
January 3, 2013 at 8:25 am
Did you get solution to this? I have same issue? Agent service account has full access on shared folder. Manually I can create files inside the folder but SQL job fails. I tried using \\Server\folder , \\server\Z$\folder and as mapped network drive but nothing works.
May 7, 2013 at 7:04 am
for your acount no permission to write the data on the network folder
possible soluation : give permissions on network folder for your acount
June 23, 2014 at 11:06 am
Your SQL Server account has to have the access to the shred drive. It means the account that your SQL Server service runs on has to have read/write/delete permissions on the network share. If the SQL Server Service account runs under the Network Service then you would have to add the computer account rights to the shared folder.
Regards,
N.
February 9, 2015 at 10:09 am
Just happened to run into this issue and SQL Agent Job history is misleading as BOL says
"Backing Up to a File on a Network Share
For SQL Server to access a remote disk file, the SQL Server service account must have access to the network share. This includes having the permissions needed for backup operations to write to the network share and for restore operations to read from it. The availability of network drives and permissions depends on the context is which SQL Server service is running..."
https://msdn.microsoft.com/en-ca/library/ms179313(v=sql.105).aspx
Viewing 15 posts - 16 through 29 (of 29 total)
You must be logged in to reply to this topic. Login to reply