I am trying to restore a .bak file from one server to another server. Please see me syntax:
RESTORE DATABASE [NewDB]
FROM DISK = '\\aps-sql111\D$\MSSQL\Backup\OLDDB.bak'
WITH
MOVE 'OLDDB' TO 'M:\MSSQL\NewDB.mdf',
MOVE 'OLDDB_log' TO 'M:\MSSQL\NewDB.ldf',
REPLACE,
STATS=10
All I keep seeing is:
Cannot open backup device ''. Operating system error 5(Access is denied.).
Any help?
it looks like you are trying to restore over the network, accessing a bak file that is not local to the destination server: with the default sql configuration you cannot do that.
the default setup is to run the sql service as a local user (network service or local service, usually): a local user cannot access resources on remote machines.
there are at least 3 solutions:
copy the file locally in a folder accessible to the user used by the sql service
change the configuration of the sql service to run as a user that can access the backup folder over the network (i would not do that on a production system)
copy the bak file on a removeble storage to move the data from source to destination (or copy the bak on a SAN/NAS that can be mapped onto the destination server)
If we want to restore database using network share as described, we must perform few steps before the restore operation itself. The network share must be mapped as a network drive in the session in which SQL Server is running.
1. Map a Network drive in File Explorer
Open File Explorer
Select This PC from the left pane. Then, on the Computer tab, select Map network drive
In the Drive list, select a drive letter.
In the Folder box, type the path of the folder or computer, or select Browse to find the folder or computer. To connect every time you sign in to your PC, select Reconnect at sign-in.
Select Finish.
2. Map a Network drive in SQLServer
Please execute following commands in SQL Server Management Studio:
exec sp_configure 'show advanced options', 1 go reconfigure go
exec sp_configure 'xp_cmdshell',1 go reconfigure with override go
xp_cmdshell 'net use z: \\server_name\drive_name passwordhere /user:DOMAIN\USERNAME'
Now you should be able to see network drive from restore wizard.
Keep in mind, however, that this ability will be removed once we restart SQL server. So to prevent this we can create a stored procedure like below and make it a startup procedure for the SQL service. This way, all of the above is done for you every time SQL starts (such as machine reboots, etc.)
Map Network Share Permanently in SSMS
Create stored procedure
CREATE PROCEDURE [dbo].[mapdrives] AS exec xp_cmdshell 'net use z: \\server_name\drive_name passwordhere /user:DOMAIN\USERNAME' GO
Enable that stored procedure to run at startup:
exec sp_procoption 'mapdrives','startup','true'
Now we can reach network drive also using PowerShell.
One way is change log on type from Built-in-account to user account on SQL Server configuration and use an user with enough permission on network.
Open SQL Server configuration management
go to SQL Server Services
Chose SQL Server ([your instance name])
Right click on service and click properties
select tab Log On
Change to This account
Browse a user with access on network directory permission
Set user and password
Restart service
If you need working on JOB Backup set this user on SQL Server Agent Service.
Related
How to fix Recovery Pending State in SQL Server Database?
Execute the following set of queries:
ALTER DATABASE [DBName] SET EMERGENCY;
GO
ALTER DATABASE [DBName] set single_user
GO
DBCC CHECKDB ([DBName], REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS;
GO
ALTER DATABASE [DBName] set multi_user
GO
For more info: https://www.stellarinfo.com/blog/fix-sql-database-recovery-pending-state-issue/
When your Database .mdf file name is renamed, this issue is occurred. To solve:
Restart SQL EXPRESS in Services, Pending issue is solved.
In our case it was caused by the disk drive running out of space. We deleted some junk to free space, then fixed the "Recovery Pending" by stopping and restarting the SQL Server Service.
Detach, re-attach, solved !
ALTER DATABASE MyDatabase SET EMERGENCY;
EXEC sp_detach_db MyDatabase
EXEC sp_attach_single_file_db #DBName = MyDatabase, #physname = N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLEXPRESS\MSSQL\DATA\MyDatabase.mdf'
While using SQL Management Studio, there is an intermittent issue when a user is changing the Database Names then sometimes SQL Server uses the same DB file for two different Databases. If SQL Server is in this state then you would be probably seeing the following error if you try Mahesh's answer:
"The process cannot access the file because it is being used by another process"
To fix this issue:
Stop MSSQLServer service from the Services Console MMC
Rename the DB and the Log files (Database Properties -> Files)
In the Object Explorer window in SQL Management Studio, refresh the 'Databases Folder', if you see that there is another Database node (in addition to the one which you are trying to rectify this issue) which is shown in 'Recovery Pending State' then proceed to the next step. If you do not see this error then you need to try something else to resolve this issue
Make a backup of the DB and Log files for new offending node from step 3 and !!Careful!! delete the database
Restore the Db File names which you changed in Step 2
Now start the MSSQLServer service from the Services Console
Re-try the steps from Mahesh's answer
In my case, this affected the secondary server in a High Availability SQL Server cluster.
The primary was Synchronizing but the secondary was Recovery Pending.
After checking in cluadmin.msc, realised that the secondary server wasn't healthy in the cluster.
Then determined Cluster Service had failed to start on the second cluster box after a Windows Update enforced reboot (may have happened because the file share witness was rebooting after a similar Windows Update at the same time).
Starting the Cluster Service brought the databases back into Synchronizing status.
Ensure that the "Log On" account for the "SQL Server (201x)" service (listed in Windows Services (Manager)) has sufficient rights. You may try changing it to another Logon. In my case, changing it from "This account" to "Local System account", restarting the "SQL Server (xxxx)" service and SQL Server Management Studio (SSMS), and logging into SSMS again resolved the issue.
Background (in my particular case):
I had 3 different instances of SQL (2008r2, 2012 and 2014) running on my local PC, and was busy moving a folder (which I later discovered contained some SQL data & log database files) to another PC. Halfway through, I stopped the SQL Services in Service (Manager), hoping that the files would move across without issues - since they would now, no longer be in use. I realized that I needed to confirm the database names, and file locations in SQL (in order to set them up again on the new pc), so I copied the SQL data and log files back (to the original locations). After restarting the PC - the majority of the databases on various instances all showed as: "Recovery Pending" in SSMS. After first trying the procedure from stellarinfo (listed as an answer here by #Mahesh Thorat) on 2 of the databases, and still not having any luck, a post SQL SERVER – Where is ERRORLOG? Various Ways to Find ERRORLOG Location on Pinal Dave's SQL Authority website and the post: Operating System error 5(Access is Denied) on SQL Server Central gave me an idea that it could be rights related after looking at the SQL Errorlog and finding "Operating system error 5: "5(Access is denied.)". Another post Msg 3201, Level 16 Cannot open backup device. Operating system error 5(Access is denied.) at SqlBak Blog seems to support this.
I was using azure, the mdf and log file are in different disk and not attached that disk with which it is not able to figure that files and hence the file Recovery Pending
This could happen due to insufficient permissions for a folder with database files (in my case due to a domain migration).
Just give access to the folder for an SQL service's account.
I want to check that a file exists on a web server using the SQL Server.
I have tried the xp_cmdshell DIR. But it works only for local files.
Please let me know how to achieve this.
Thanks in advance.
After searching for a few days, I found the following which works well :-
When you have to put file, like BCP result, or a backup in a remote drive, just map this drive into windows don't work, it must be mapped on SQL Server to!, to do this, try like this:
exec xp_cmdshell 'net use p:\ \Server\Folder\Folder\Folder\ /Domain\Login /Password'
Reference :
https://social.msdn.microsoft.com/Forums/en-US/6eca2d62-eb86-4f23-9b86-6f917017f50c/bcp-utility-via-xpcmdshell-and-network-drive?forum=sqlsecurity
You can not access with any user, means while access directory in sqlserver you have to only use that user which have directory rights and your sqlserver services running in that user.
if you access in normal user or say simply Network Service or 'Local Service' user (in which sqlserver service run default) you can access all resources of your computer via network too (ie. \yourname\sharablefolder ), but not access sharable folder in the network.
either backup resore : http://www.sqlservercentral.com/Forums/Topic631787-146-1.aspx
or execute command :
http://www.sqlservercentral.com/Forums/Topic808580-359-1.aspx
how can i access a file/folder over network through XP_CMDSHELL in sql server 2008?
https://www.simple-talk.com/community/forums/thread/72262.aspx
https://social.msdn.microsoft.com/forums/sqlserver/en-US/c5ce5e21-17e7-4763-ba68-d3bb7dad213f/access-denied-on-xpcmdshell-with-certain-folders
I'm trying to set up a Stored Procedure as a SQL Server Agent Job and it's giving me the following error,
Cannot bulk load because the file "P:\file.csv" could not be opened. Operating system error code 3(failed to retrieve text for this error. Reason: 15105). [SQLSTATE 42000] (Error 4861)
Funny thing is the Stored Procedure works just fine when I execute it manually.
The drive P: is a shared drive on Windows SQL Server from LINUX via Samba Share and it was set up by executing the following command,
EXEC xp_cmdshell 'net use P: "\lnxusanfsd01\Data" Password /user:username /Persistent:Yes'
Any help on this would be highly appreciated
I do not know if you solved this issue, but I ran into the same issue. If the instance is local you must check the permission to access the file, but if you are accessing from your computer to a server (remote access) you have to specify the path in the server, so that means to include the file in a server directory, that solved my case.
example:
BULK INSERT Table
FROM 'C:\bulk\usuarios_prueba.csv' -- This is server path not local
WITH
(
FIELDTERMINATOR =',',
ROWTERMINATOR ='\n'
);
To keep this simple, I just changed the directory from which I was importing the data to a local folder on the server.
I had the file located on a shared folder, I just copied my files to "c:\TEMP\Reports" on my server (updated the query to BULK INSERT from the new folder). The Agent task completed successfully :)
Finally after a long time I'm able to BULK Insert automatically via agent job.
Best regards.
I have solved this issue,
login to server computer where SQL Server is installed get you csv
file on server computer and execute your query it will insert the
records.
If you will give datatype compatibility issue change the datatype for that column
Using SQL connection via Windows Authentication:
A "Kerberos double hop" is happening: one hop is your client application connecting to the SQL Server, a second hop is the SQL Server connecting to the remote "\\NETWORK_MACHINE\". Such a double hop falls under the restrictions of Constrained Delegation and you end up accessing the share as Anonymous Login and hence the Access Denied.
To resolve the issue you need to enable constrained delegation for the SQL Server service account. See here for a good post that explains it quite well
SQL Server using SQL Authentication
You need to create a credential for your SQL login and use that to access that particular network resource. See here
I would suggest the P: drive is not mapped for the account that sql server has started as.
It's probably a permissions issue but you need to make sure to try these steps to troubleshoot:
Put the file on a local drive and see if the job works (you don't necessarily need RDP access if you can map a drive letter on your local workstation to a directory on the database server)
Put the file on a remote directory that doesn't require username and password (allows Everyone to read) and use the UNC path (\server\directory\file.csv)
Configure the SQL job to run as your own username
Configure the SQL job to run as sa and add the net use and net use /delete commands before and after
Remember to undo any changes (especially running as sa). If nothing else works, you can try to change the bulk load into a scheduled task, running on the database server or another server that has bcp installed.
I did try giving access to the folders but that did not help.
My solution was to make the below highlighted options in red selected for the logged in user
I want to restore a database from a file (Tasks → Restore → Database; after I select from device and select file) via SQL Server Management Studio.
After that, I get this error:
The operating system returned the error '5(Access is denied.)' while attempting
'RestoreContainer::ValidateTargetForCreation' on 'E:\Program Files\Microsoft SQL
Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\XXXXXX.mdf'.
Msg 3156, Level 16, State 8, Server XXXX, Line 2
How do I fix this problem? Is it a security error?
I recently had this problem. The fix for me was to go to the Files page of the Restore Database dialog and check "Relocate all files to folder".
The account that sql server is running under does not have access to the location where you have the backup file or are trying to restore the database to. You can use SQL Server Configuration Manager to find which account is used to run the SQL Server instance, and then make sure that account has full control over the .BAK file and the folder where the MDF will be restored to.
Well, In my case the solution was quite simple and straight.
I had to change just the value of log On As value.
Steps to Resolve-
Open Sql Server Configuration manager
Right click on SQL Server (MSSQLSERVER)
Go to Properties
change log On As value to LocalSystem
Hoping this will help you too :)
I just ran into this same problem but had a different fix. Essentially I had both SQL Server and SQL Server Express installed on my computer. This wouldn't work when I attempted to restore to SQL Express, but worked correctly when I restored it to SQL Server.
A good solution that can work is go to files > and check the reallocate all files
I tried the above scenario and got the same error 5 (access denied). I did a deep dive and found that the file .bak should have access to the SQL service account. If you are not sure, type services.msc in Start -> Run then check for SQL Service logon account.
Then go to the file, right-click and select Security tab in Properties, then edit to add the new user.
Finally then give full permission to it in order to give full access.
Then from SSMS try to restore the backup.
I was getting the same error while trying to restore SQL 2008 R2 backup db in SQL 2012 DB. I guess the error is due to insufficient permissions to place .mdf and .ldf files in C drive. I tried one simple thing then I succeeded in restoring it successfully.
Try this:
In the Restore DB wizard windows, go to Files tab, change the restore destination from C: to some other drive. Then proceed with the regular restore process. It will definitely get restores successfully!
Hope this helps you too. Cheers :)
There are several causes for this error, I got this error because I checked "Reallocate all files to folder" in the Files tab of Restore Database window but the default path did not exist on my local machine. I had the ldf/mdf files in another folder, once I changed that I was able to restore.
The operating system returned the error '5(access denied.)' when restoring database in sql server can be solved by enabling the Relocate all files to folder in the Files options as follows:
I found this, and it worked for me:
CREATE LOGIN BackupRestoreAdmin WITH PASSWORD='$tr0ngP#$$w0rd'
GO
CREATE USER BackupRestoreAdmin FOR LOGIN BackupRestoreAdmin
GO
EXEC sp_addsrvrolemember 'BackupRestoreAdmin', 'dbcreator'
GO
EXEC sp_addrolemember 'db_owner','BackupRestoreAdmin'
GO
In my case I had to check the box in Overwrite the existing database (WITH REPLACE) under Options tab on Restore Database page.
The reason I was getting this error: because there was already an MDF file present for the database and it was not getting overwritten.
Hope this will help someone.
If you're attaching a database, take a look at the "Databases to attach" grid, and specifically in the Owner column after you've specified your .mdf file. Note the account and give Full Permissions to it for both mdf and ldf files.
I had exactly same problem but my fix was different - my company is encrypting all the files on my machines. After decrypting the file MSSQL did not have any issues to accessing and created the DB. Just right click .bak file -> Properties -> Advanced... -> Encrypt contents to secure data.
this happened to me earlier today, i was a member of the local server's admin group and have unimpeded access, or i thought so. I also ticked the "replace" option, even though there is no such DB in the instance.
Found out that there used to be DB of the same name there, and the MDF and LDF files are still physically located at the data and log folders of the server, but the actual metadata is missing in the sys.databases. the service account of SQL server also can't ovewrwrite the existing files. Found out also that the files' owner is "unknown", i had to change ownership, to the 2 files above so that it is now owned by the local server's admin group, then renamed it.
Then finally, it worked.
The account does not have access to the location for backup file.
Take the following steps to access the SQL Server Configuration Manager via Computer Manager easily
Click the Windows key + R to open the Run window.
Type compmgmt.msc in the Open: box.
Click OK.
Expand Services and Applications.
Expand SQL Server Configuration Manager.
Change User Account in Log On As tab .
Now you can Restore Data Base easily
The fix for me was to go into Options when trying to Restore the database and change the path to the new path.
Here is the screenshot
I encountered the same problem, but my setup is a bit different.
I run my database in a linux docker container
sqlserver management tool in Windows.
What I did was:
sudo docker exec -u root -it sqlserver /bin/bash
This enters the docker container as a root user.
Then:
chmod 777 /path/to/file.bak
777 gives read, write & execute permissions to the file for any group, user
How do you restore a database backup using SQL Server 2005 over the network? I recall doing this before but there was something odd about the way you had to do it.
You have few options to use a network file as a backup source
Map network drive/path, hosting file, under SAME user as MS-SQL Server.
Use xp_cmdshell extended stored procedure to map network drive from inside of MS SQL (such way, command shell will have the same privilegies as the user account running SSMS)
-- allow changes to advanced options
EXEC sp_configure 'show advanced options', 1
GO
-- Update currently configured values for advanced options.
RECONFIGURE
GO
-- To enable xp_cmdshell
EXEC sp_configure 'xp_cmdshell', 1
GO
-- Update currently configured values for advanced options.
RECONFIGURE
GO
EXEC xp_cmdshell 'NET USE Z: \\Srv\Path password1 /USER:Domain\UserName'
Afterwards drive Z: will be visible in Server Managment studio, or just
RESTORE DATABASE DataBaseNameHere FROM DISK = 'Z:\BackNameHere.BAK'
GO
The database is often running as a service under an account with no network access. If this is the case, then you wouldn't be able to restore directly over the network. Either the backup needs to be copied to the local machine or the database service needs to run as a user with the proper network access.
You cannot do this through the SSMS GUI, but you can do it using a script. RESTORE DATABASE from DISK='\unc\path\filename' If you need this process automated, the best way is to setup a SQL Server Job and run it as a user with access to the file location.
You can use the SP xp_cmdshell to map the networkdrive for sql server, after that it will show up in the file browsing window.
EXEC xp_cmdshell 'NET USE Z: SERVERLOCATION PASSWORD /USER:DOMAIN\USERNAME'
more info here: DB Restore from Network Drive
Worked for me!
Make sure that the user running your SQL services in "Services.msc" is an active directory "Domain User" this will fix the issue.
I've had to do this a few times, and there are only two options that I know of. Copy the file locally to the SQL Server, or on the SQL server create a mapped network drive to the share that contains the backup file.
Also, you need to make sure that the SQL Server Service is running as a user that has network access - and permissions to the share where the backup file lives. 'Local System' won't have permissions to access the network.
As a side note, if you happen to be running SQL on a Virtual Machine it's often less hassle to just temporarily set up a new drive on the VM with enough space to copy your backup files to, do the restore from that new local copy, and then delete the temp drive.
This can be useful if stopping/starting the SQL service to change it's account is an issue.
Create a shared drive on machine that has the backups, say server1 has the backups in folder "Backups". Grant full control to the account running the SQL Server. On the Server that you want to restore to launch SSMS go restore database and select "From Device". In the "Locate Backup file-"Server"" dialog box and remove anything in the "Selected Path" field and in the "File Name" field supply full path so "\server\backups\db.bak". At least it worked for me when migrating from 05 to 08. Not the preferred method because any network hiccup can cause an issue with the restore.
EXEC sp_configure 'show advanced options', 1
GO
-- Update currently configured values for advanced options.
RECONFIGURE
GO
-- To enable xp_cmdshell
EXEC sp_configure 'xp_cmdshell', 1
GO
-- Update currently configured values for advanced options.
RECONFIGURE
GO
--This should be run on command prompt (cmd)
NET USE Z: \\172.100.1.100\Shared Password /USER:administrator /Persistent:no
then on SQL Server
EXEC xp_cmdshell 'NET USE Z: \\172.100.1.100\Shared Password /USER:administrator /Persistent:no'
--Afterwards drive Z: will be visible in Server Management studio, or just
RESTORE DATABASE DB FROM DISK = 'Z:\DB.BAK'
WITH REPLACE