DB restore file must not be in C:\Temp

Question

DB restore file must not be in C:\Temp

Alan Spillert

SSCommitted

Points: 1964
More actions
May 21, 2013 at 8:40 am

#278097

I copied a full backup of my SQL Server 2008R2 production database to the directory C:\Temp on my SQL Server 2012 test server (both Windows Server 2008R2), and tried to restore it to a newly created database. I selected the device and located the backup file, but do not see it, so pasted the file name in. Then selected the destination database (the new SS12 db), selected "Overwrite the existing database", but do not see a backup set. "OK" is grayed out, and the top of the Restore task screen says "No backupset selected to be restored".
Then I copied the same backup file from C:\Temp to C:\Backup, on the same server, and the Restore screen can now see the backup file. I also copied it to C:\Restore and the SQL Server 2012 likes that directory too.
Why must the restore file not be in C:\Temp? Or am I not understanding the real problem?
Thank you for your help.

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply

David Webb-CDS SSCoach Points: 17398 More actions · Answer 1

I don't think there is anything magical about c:\temp. Does the account the SQL Server is running under have access to that directory? I'd guess that it's more likely a permissions issue than anything else.

And then again, I might be wrong ...
David Webb

Steve Jones - SSC Editor SSC Guru Points: 736479 More actions · Answer 2

I would agree with David. The service account of the SQL Server database engine must be able to see the folder. By default, the list of folders is fairly well locked down.

Alan Spillert SSCommitted Points: 1964 More actions · Answer 3

The service account that is running the MSSQLSQLServer is in the "Administrators" group, SQL Server management Studio is "Run as Administrator", and the service account has "db_owner". There is no special security on the "Temp" directory.

That said, it is probably security, but I can't find it. I get about the same error when trying to restore from T-SQL:

Msg 3201, Level 16, State 2, Line 2

Cannot open backup device 'C:\Test\CHxxx_backup_2013_05_20_190005_1282827.bak'. Operating system error 3(The system cannot find the path specified.).

Msg 3013, Level 16, State 1, Line 2

RESTORE DATABASE is terminating abnormally.

Thank you for your help.

Are there any services that might put special security on the "Temp" directory?

george sibbald SSC Guru Points: 104210 More actions · Answer 4

[quote-0Msg 3201, Level 16, State 2, Line 2

Cannot open backup device 'C:\Test\CHxxx_backup_2013_05_20_190005_1282827.bak'. Operating system error 3(The system cannot find the path specified.).

Msg 3013, Level 16, State 1, Line 2

RESTORE DATABASE is terminating abnormally.

[/quote-0]

that says c:\test rather than c:\temp?

---------------------------------------------------------------------

Lowell SSC Guru Points: 323518 More actions · Answer 5

most likely permissions, as previously identified, but maybe i can help you find out the specifics.

if i right click on my temp folder, and go to the security tab, i see everyone who has permissions.

* Note that NT Authority\Network Service DOES NOT have permissions)

folders like \Users\username\Desktop are the same situation.

now remember that when you access any resource OUTSIDE of SQL server, a security context that is not intuitively understood is used instead.

When accessing network shares, local hard drives and folders via xp_cmdshell, bcp with a "trusted" connection, sp_OA type functions etc.

it doesn't matter what YOUR credentials are. Whether you are Domain Admin,Local Admin , logged in as sa, administrative login on a laptop, etc, because SQL will not carry those credentials to the "outside of SQL" security context.

SQL WILL pass your credentials to a linked server, but anything else is using an account you did not intuitively expect it to use.

SQL Server uses either the account set up as the proxy account, or if that is left blank(the default) it uses account it starts with to try and access the resource:

or if the above was blank, the account in services:

That account is often an account which has never logged into the domain, and was never assigned permissions to get to the local disk or network share.

As a result, you usually need to create a domain account in Active Directory, specifically grant it share access if it doesn't inherit it from Domain\Users or Domain\AuthenticatedUsers and change the account SQL Server starts with to that account.

Once that is done, and you stop and start the SQL service to make it use that account instead of old running values, your linked server/xp_cmdshell would work.

you can prove this is the issue by simply putting in your credentials, with your domain account and password, and confirm the external object you were trying to access/use works when SQL is run your credentials, so you'd know you need a domain account to access the resource.

Lowell

--help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!

Alan Spillert SSCommitted Points: 1964 More actions · Answer 6

Lowell,

This was a big help - thank you. I changed the SQL Server service account to be the key application's account, and logged in with that account. It had been in the Admin group. I changed the directory and file to give this account full control, and was able to do the restore.

Alan