June 29, 2011 at 2:42 pm
I have log shipping set up between two instances.
Share1 is for the primary to store backups.
Share2 is for the secondry to copy tran backups over two, from where they are restored to instance2.
The Agent account and sql account on instance2 are the same. This account has full read/write access to both copy and destination shares/directories.
When i take the path from the error message in the job history, i can hit the directory with no issues.
If the sql account has full access to that share, why is it throwing this error?
Note, the account that instance2 agent and server is running under is in no groups on my server at all. It is also a local account, created on the server. Does it need to be in some groups to ensure it can access folders perhaps?
Update: I have made the service account an admin on the box, along with giving it Sysadmin access to the server but still no luck.
June 29, 2011 at 3:58 pm
something wrong with the accounts i created. couldnt even do a restore database with them. kept getting the error "while attempting 'RestoreContainer::ValidateTargetForCreation'.... "
changed to local service and can now restore. Will see if i can do log shipping tomorrow with local service, and with new accounts.
July 3, 2011 at 1:31 pm
Ì have tried this with two new accounts.
both have admin acces.
I have logged in with both accounts and can access the backup share, and all other shares.
When i run the job under the accounts though i get the same error:
Error: The copy destination directory '\\mypc\c$\backup' does not exist.
i have no idea what is wrong here. its defo not a permissions issue.
July 3, 2011 at 1:56 pm
I've seen cases where permissions changed but running processes didn't not recognize those changes. Did you have to grant the SQL login admin level access? Have you restarted SQL since? Also, the C$ share is an administrative share so only members of the Administrators group will have access. You might consider creating a share at the location you want to access.
CEWII
July 3, 2011 at 3:04 pm
Elliott Whitlow (7/3/2011)
I've seen cases where permissions changed but running processes didn't not recognize those changes. Did you have to grant the SQL login admin level access? Have you restarted SQL since? Also, the C$ share is an administrative share so only members of the Administrators group will have access. You might consider creating a share at the location you want to access.CEWII
Hi.
Yes, I have granted the SQL Login sysadmin access in the instance, and the computer account associated with it is in the Administrators Group ( this is all running on my local pc).
The share is not directly on the c drive, its in a share whos fully qualified path is c:\sqlserver\logshipping\DestinationShare.
UPDATE: its started working. Unfortunately i did not go step by step, but the last 3 steps i applied are:
1. based on a token error, i disabled UAC. This didnt resolve anything initially so i re-enabled it ( restarted the pc both times).
2. I removed and re-added the accounts to the admin group on the pc.
3. I disabled ipv 6 due to a strange dhcp error.
its working now. wish i knew what was causing this to occur.
I would also preferr the sql agent account was not in the admin group, its not something that would be allowed on a production server.
July 3, 2011 at 3:13 pm
i wonder if it could have been an issue with the fact that i connect to a few VPN's with my personal laptop. It could have been trying to validate the account against a DNS('s) that im no longer conneted to.
is this a possibility?
July 3, 2011 at 11:54 pm
Are both machines joined to the same domain or are they stand alone servers?
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
July 4, 2011 at 7:43 am
all instances on my own personal machine.
my machine has been part of many domains and VPN's in the last week though, bit of a domain slut.
July 4, 2011 at 8:37 am
winston Smith (7/4/2011)
all instances on my own personal machine.
so, standalone then.
what user account do the sql server services run under?
What ACLs have you applied to the NTFS permissions and the share permissions?
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply