Related
On Ubuntu 17.04, I have a .bak file in /var/opt/mssql/backup/ that I am trying to restore to a separate partition because the partition I have SQL Server installed on does not have enough room for the database to be restored to.
I am getting an error like the following: The operating system returned the error '5(Access is denied.)' while attempting 'RestoreContainer::ValidateTargetForCreation' on '/media/<my-user-name>/<some-folder>/<mdf-file>.mdf'.
I've tried to use chmod and chown to change the permissions of that folder on the second partition, but I'm not getting it quite right because I still get the error.
What user is trying to write to that folder in the second partition?
How do I get that user account permissions to successfully restore the database to that folder?
I had this second hard drive connected via a caddy and was able to perform this task no problem. But as soon as I installed the ssd internally, Ubuntu has not allowed whatever user account I'm using in the SQL Server CLI for it this time.
Thanks!
Update
I changed the owner of the second partition/ssd to mssql and now I have permission to restore the database to this location. I would assume that if the owner of that whole ssd is mssql, I might have other permission issues down the road using this ssd for other things. Is there a way to configure this so that my personal user account as well as mssql has permissions to this folder enough to own it? I don't think two different accounts can own a folder, but is there a way to permit multiple accounts with sufficient access to perform these actions?
I won't pretend to be knowledgeable about this, but I had a permissions issue while trying to restore a .bak that was on a network vm to my local device, it worked when I added it to a .zip with 7-share, then copied it to the location I wanted and extracted it.
I had the permissions issue when I tried to move it without zipping, and as far as I remember I still had this issue when I used send to compressed (zipped) folder. I'm not sure why, maybe someone else can elaborate
I solve the problem by deleting the old database, creating a new one and restoring the backup to the new one.
My problem was probably cause by the fact that I had created the database in evalutation edition of MS SQL Server and I wanted to rewrite it by backup in new instalation of developer edition.
i am trying to attach external database named ( HaseebProject.mdf) but every time i got an error
" An error occurred when attaching the database(s). Click the hyperlink in the Message column for details."
What'sthe error is there..?? even there is any error message in message field as shown.
When i click on add button to add database there are two paths in directory for database. i have tried with both but he same error.
Try running SQL Server Management Studio as administrator
All of the answers I've seen so far are possible suggestions of what could be the issue, but it doesn't necessarily help you identify the issue that's preventing you from attaching this database.
The error message you are referring to is actually pointing you to a more specific error message for your case. This more specific error message is located in the Message column of the "Attach Database" window that you've already opened (you may just need to scroll to the right of the "Databases to attach" section and click on the message to see it in its entirety.
I had this problem as well, I did right click on (.mdf and .ldf) the file then on the security tab, click on Edit.
In a new window find the users and set permission to full control. If you can't find users click on:
add button-->advanced-->Find now-->find users
and then click on Ok.
if it doesn't work you can backup from your database and restore it instead of attaching. I have done it and it works.But before restoring make sure that your DB (.mdf and .ldf) shouldn't exist in SQL server database directory before restoring (it's up to your SQL server installation path in my case -->C:\Program Files\Microsoft SQL Server\MSSQL12.SQL2014\MSSQL\DATA) otherwise you will face to an error
Navigate to the directory containing the database and open the
properties for the folder.
Go to the Security tab, Edit permissions, Add User.
In Locations, select the location that is hosting the server.
In object names, Enter NT Service\MSSQL$<Instance-Name> (e.g. NT
Service\MSSQL$MSSQLSERVER).
Set Permissions to full control and save.
This will give your SQL Server instance full permissions for the target directory.
Right-click on the MyDataBase.MDF file
Select Properties -> Go to Security tab -> Select Edit -> Select Add -> Select Advanced -> Select Find Now -> Selecte User Administrator & User Everyone
Set permissions to full control for both
Click OK
Clear MyDataBase_log.LDF file
Copy MyDataBase.MDF file to this location:
(C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA)
Run SQL Server Management Studio as an administrator
Attach MyDataBase.MDF file from this address:
(C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA)
If you already have a database with the same name, delete it before you try to attach the .mdf file. My issue was that they were named the same.
Ryan Harris mentioned looking at the error message, this helped me a lot. So look at that first, you might have a different issue.
SQL message
I had the same issue. The problem was the disk which I was transferring the database file. So if you are copying the database file from one computer to another computer make sure the removable disk is not corrupted. Always try a second removable disk. And also don't forget to run SSMS as administrator.
Use this command to attache db from .mdf file
USE [master]
GO
CREATE DATABASE [SchoolDB] ON
( FILENAME = N'C:\SchoolDB.mdf' )
FOR ATTACH
GO
I had the same issue. After I expanded the error message, I found that it was saying the .MDF file was compressed.
I googled the issue and found this resource that solved my issue.
https://blogs.msdn.microsoft.com/sqlblog/2006/10/02/sql-server-databases-are-not-supported-on-compressed-volumes/
If your error is similar to this:
Create failed for Database 'Compressed_DB'. (Microsoft.SqlServer.Smo)
An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)
The file "E:Compressed_DB.mdf" is compressed but does not reside in a read-only database or filegroup. The file must be decompressed.
CREATE DATABASE failed. Some file names listed could not be created. Check related errors. (Microsoft SQL Server, Error: 5118)
Then you can right click the folder in which the .MDF file resides, click "Properties".
Click "Advanced" in the General tab, and uncheck "Compress contents to save disk space"
This solved the error I was getting, so try it out and attach your .MDF again.
In my case I changed the main database file names so I had to select them again using button in "Current File Path" column.
Resolution:- Just give permission to database folder and attached mdf file then.
check version of the sql server software and the sql software that mdf was created. must be the same versions.
I created a database on my local machine and then did a backup called tables.bak of table DataLabTables.
I moved that backup to a remote machine without that table and tried to do a restore but get the following error:
System.Data.SqlClient.SqlError: The operating system returned the
error '5(Access is denied.)' while attempting
'RestoreContainer::ValidateTargetForCreation' on 'c:\Program
Files\Microsoft SQL Server\MSSQL.1\MSSQL\DataLabTables.mdf'.
How do I fix my rights, if that is the problem?
I have just had this issue with SQL Server 2012.
It turns out all I had to do was tick the box marked 'Relocate all files to folder' on the 'Files' section:
(Click to see image full size)
This of course assumes you have the correct version of SQL Server installed.
From the error message, it says there's an error when validating the target (c:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DataLabTables.mdf) of your restore operation.
That sounds like:
a) that file already exists (because you've already restored it previously) and is in use by SQL Server
or
b) that directory doesn't exist at all
In your question, you mentioned you created a backup for that table - that's not how SQL Server backups work. Those backups are always the whole database (or at least one or several filegroups from that database).
My hunch is: you've already restored that database previously, and now, upon a second restore, you didn't check the checkbox "Overwrite existing database" in your restore wizard - thus the existing file cannot be overwritten and the restore fails.
The user that's running the restore on your remote server obviously doesn't have access to that directory on the remote server.
C:\program files\.... is a protected directory - normal (non-admin) users don't have access to this directory (and its subdirectories).
Easiest solution: try putting your BAK file somewhere else (e.g. C:\temp) and restore it from there
I was having the same problem. It turned out that my SQL Server and SQL Server Agent services logon as were running under the Network Services account which didn't have write access to perform the restore of the back up.
I changed both of these services to logon on as Local System Account and this fixed the problem.
Recently I faced this issue with SQL 2008 R2 and the below solution worked for me:
1) Create a new database with the same name as the one you are trying to restore
2) While restoring, use the same name you used above and in the options, click the overwrite option
You might give the above a shot if the other solutions don't work.
The backup creator had MSSql version 10 installed, so when he took the backup it also stores the original file path (to be able to restore it in same location), but I had version 11, so it could not find the destination directory.
So I changed the output file directory to C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\, and it was able to restore the database successfully.
Source
I had a similar problem. I tried to restore a 2005 .bak file, and i received exactly the same error. I selected the overwrite option as well to no avail.
my solution was to grant the SQL user access to the directory in question, by going to the folder and editing the access rights through the property screen.
lost a couple of hours to this problem too. got it going though:
"access denied" in my case really did mean "access denied". mssqlstudio's user account on my windows device did NOT have full control of the folder specified in the error message. i gave it full control. access was no longer denied and the restore succeeded.
why was the folder locked up for studio ? who knows ? i got enough questions to deal with as it is without trying to answer more.
I had this issue, I logged in as administrator and it fixed the issue.
Another scenario could be the existence of multiple database paths. First, make note of the path where new databases are currently being stored. So if you create a new empty database and then do Tasks/Restore, make sure that the path the restore is trying to use is the same directory that the empty database was created in. Even if the restore path is legal, you will still get the access denied error if it is not the current path you are working with. Very easy to spot when the path is not legal, much harder to spot when the path is legal, but not the current path.
Sorry because I cannot comment...
I had the same problem. In my case the problem was related to trying to restore in an old sql server folder (that existed on the server). This is due to old sql server backup (i.e. SQL Server 2012 Backup) restored in a new sql server (SQL Server 2014). The real issue is not too different from #marc_s answer. Anyway, I changed only the target folder to the new SQL Server DATA folder.
This may not be the best solution, but I was trying to do the restore at SQL Server 2005, but I changed to SQL Server 2008 and it worked.
Got problem like this. Error caused by enabled compression on SQL Server folders.
Frnds... I had the same issue while restroring database and tried every solution but could nt get resolved. Then i tried to re install SQL 2005 and the problem solved. Actully last time i forgot to check on customize option while instlling SQL.. It comes two times while installing and i checkd it for ones only..
In my case - I had to double check the Backup path of the database from where I was restoring. I had previously restored it from a different path when I did it the first time. I fixed the Backup path to use the backup path I used the first time and it worked!
I ended up making new folders for Data and Logs and it worked properly, must have been a folder/file permission issue.
This also happens if the paths are correct, but the service account is not the owner of the data files (yet it still has enough rights for read/write access). This can occur if the permissions for the files were reset to match the permissions of the folder (of course, while the service was stopped).
The easiest solution in this case is to detach each database and attach it again (because when attaching the owner is changed to be the service account).
Try this:
In the Restore DB wizard window, go to Files tab, Uncheck "Relocate All files to folder" check box then change the restore destination from C: to some other drive. Then proceed with the regular restore process. It will get restored successfully.
I had the same problem but I used sql server 2008 r2, you must check in options and verify the paths where sql going to save the files .mdf and .ldf you must select the path of your sql server installation. I solved my problem with this, I hope it helps you.
Then try moving it to a sub folder under the C:, but verify that the user has full rights on the folder your use.
I'm running the copy database wizard on a 2008 R2 instance of SQL Server.
The database I want to copy is a SQL 2000 database.
I'm copy that database to another SQL SErver 2008 R2.
The wizard uses SQL authentication for both servers, and both are sysadmins.
When I run it, I get the following error (FYI I have tried both copying the logins and leaving them out):
Event Name: OnError
Message: ERROR : errorCode=-1073548784 description=Executing the query "sys.sp_addrolemember #rolename = N'RandomRoleName..." failed with the following error: "The role 'RandomRoleName' does not exist in the current database.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
helpFile= helpContext=0 idofInterfaceWithError={C81DFC5A-3B22-4DA3-BD3B-10BF861A7F9C}
StackTrace: at Microsoft.SqlServer.Management.Dts.DtsTransferProvider.ExecuteTransfer()
at Microsoft.SqlServer.Management.Smo.Transfer.TransferData()
at Microsoft.SqlServer.Dts.Tasks.TransferObjectsTask.TransferObjectsTask.TransferDatabasesUsingSMOTransfer()
Any help would be appreciated!
Jim
My suggestion is dont use the copy database wizard. Create a full backup of the database on the 2000 server and then restore it on the 2008 server.
If you google "Microsoft.SqlServer.Management.Dts.DtsTransferProvider.ExecuteTransfer Copy Database Wizard" you will find that many many people have gotten this same error or other nearly identical smo errors... no-one appears to have gotten past it.
That's isn't to say its impossible... just, restoring a backup is so much easier then the wizard or troubleshooting the wizard. Good luck.
The copy wizard had missed some security and IIRC it's caused by subtle differences in security tables, principals etc between the 2 versions.
Frankly, the easiest way is to do one of these two:
backup/restore
detach, copy, attach
If you don't have access to the O/S and can't get it, another option is to create the missing role(s) in the background as the copy runs. You have to catch it between the creation of the files and when it tries to reference the roles, but there are a few seconds in which to create them if you keep clicking execute - I managed to create 9 roles.
Unfortunately, you'll end up with the roles in another database too (while yours cannot be used) so those need to be deleted.
Of course, this is only an option when you really can't use the other method.
Though the answer which is using the backup technique solves the problem generally, after facing the same issue several times, I was able to trace down the root of the problem using the Event Viewer of Windows to that the Database Copy wizard, using the SQL Agent, will eventually create a Job for the agent to run, after which the Agent will run using its own credentials (i.e. the credentials that you can look up in Windows Services, in my case, NT Service\SQLAgent$SQL2014)
All you need to do is to go the folder where SQL Server creates DB files (e.g. C:\Program Files\Microsoft SQL Server\MSSQL12.SQL2014\MSSQL\DATA by default for SQL 2014) and give the SQL Agent windows user write/read access on the folder.
The reason can be that a file with the new Database name already exist on the filesystem. We encountered this when we renamed Database X to X_Old, and tried to copy database Y to X. This cannot be done, because database X_Old is still associated with the filename X.
Either delete the conflicting database, or rename the file on the file system.
See http://codecopy.wordpress.com/2012/01/03/error-while-copying-a-database/
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