Related
I am trying to run a classic asp project on visual studio and therefore I am trying to restore a database. I cannot seem to find the .bak file when trying to restore it. It wasn't visible in the C-drive. I have looked it up and have seen that it has something to do with permissions. I have tried enabling permissions after properties>security of .bak file to 'Everyone', it did not work. I have also tried NT Service\MSSQLSERVER. Please see the following below.
I had the same issue. I get to know that it was a a permissions issue.
Here are the following steps to solve this problem
Go to Control panel > Administrative Tools > Services double click on the services.
copy the log on account name of sql service as shown in the picture.
Go to your backup folder and right click and select properties.
Follow the steps as shown in picture.
After clicking on edit you will get new window.
Click on add
Paste here the Log on account name of sql service account which you had copied earlier. then Click on check name button.
Select MSSQLSERVER then click ok.
Now you will get your sql server account name in security tab.
Select sql server account name that and in permission box select Allow in all check boxes(I added Full Control) then click apply.
Now you will be able to select and restore your backup file.
You also have to enable permissions to the folder where the file is located. SSMS first needs to browse the folder, then to read the file.
In your case, SQL server tries to access the folder using NT Service\MSSQLSERVER account, so permissions should be granted to that account, no need to give more permissions (to everyone).
Also try below if above doesn't help:
close/open SSMS
move the file from root to some folder and grant permissions to that folder
use TSQL script to restore the database instead of SSMS
you can copy the backup folder in to C:\Users\MSSQL$HCMIS\Desktop sql server users folder.Now it will be accessible
I'm facing simpler issue for sql server standalone 2014 enterprise edition ,installed in my home system . I tried every possibility provided in various article but strangely the issue is with my 2 named instance .
I can restore database on my default instance with query and GUI . I tried changing log-on as account of sql server service for named instance to 'network service' or 'local system' and giving them full control permission to backup holding folder .
In my (and probably a typical/common case): I looked through (and compare with other .bak files) in the windows permission and see nothing wrong.
However - This may be due to that one does not follow to restore from the [device] option first. Even you store the .bak in the right path, it is initially from the [Source]->[Database] check box, until you follow the steps to restore via the [device] option
(In my case the second AdventureWorksDW2020-DAX-Docs was not available until I go thru extra steps to restore it via the [Device] option first.)
The SQLserver need to do internal access right grants to users... etc..(even all the needed Windows properties are in place) –
Reference https://learn.microsoft.com/en-us/sql/samples/adventureworks-install-configure?view=sql-server-ver16&tabs=ssms
I have this update tool for my program. The tool updates the SQL Server database with this code (vb and sql).
Dim sql As Process = Process.Start("sqlcmd.exe", Param + " -i update.sql -o log.txt")
Param contains the name of the .bak file myprogram_update.bak among others.
update.sql starts with
RESTORE DATABASE [myprogram_tmp]
FROM DISK = N'$(db_src)'
WITH FILE = 1,
MOVE N'myprogram_tmp' TO #mdf,
MOVE N'myprogram_tmp_log' TO #ldf,
NOUNLOAD, STATS = 5
#mdf and #ldf are standard paths read from the SQL Server settings.
The update tool is shipped to customers and the problem is that usually SQL Servers aren't allowed to read in user directories of windows like Desktop or Downloads. But many customers unzip the archive to these directories and then they get this error.
Could not access myprogram_update.bak / access denied.
I can't change the settings on every customers server, so is there any way to make it work for these directories? One idea of mine was to run a setup first and unzip it to program files but maybe there is a smarter solution.
Edit: the tool runs in administrator mode.
You should ask for elevation and run as an administrator account, maybe this will help:
http://www.downloadinformer.com/how-to-make-a-vb-net-application-always-run-in-administrator-mode/
I've now put my program into an setup which is usually installed under an ordinary folder, like C:\Program Files (x86)\MyProgram. Here SQL-Server has access.
Installation of SSMS 2012 alongside any other existing SSMS installation, such as SSMS 2008 R2 has a problem with setting the default program for opening .SQL files to the new SSMS 2012 version.
Dragging .sql file to the query window works successfully. However, when a user double clicks on the .sql file a new instance of 2008 R2 can open as the .sql associated entry. Changing with Default Open With makes no difference when doubleclicking on new files. Additionally, altering the command line script for the opening can perhaps achieve changing the .sql to opening in SSMS 2012, but it still causes repeated instances of ssms instead of using the existing instance (causing additional load and memory usage).
Adapted from this post on how to how to fix .sql file not opening with SSMS 2008, you should start by opening up the registry (regedit)
Go to HKEY_CLASSES_ROOT\.sql and change the default value to ssms.sql.11.0 (SSMS 2012 is v11 of the product). This tells your computer the application string it should look for when trying to open files of type .sql
The registry takes that name you just entered and then looks up what to actually go do in another registry setting.
Go HKEY_CLASSES_ROOT\ssms.sql.11.0\Shell\Command and change the default value to:
"C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\ssms.exe" "%1" /dde
Turn your computer off and on again for good measure.
If it still doesn't work for whatever reason. Right click on any SQL file. Go to Properties and click to change the file it opens with. You may have two SQL options available. Try one then the other.
To change to default entry I utilized an application that displayed the DDE (dynamic data exchange) values. I personally used FileTypesMan.
I then changed the command line for SSMS to:
"C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\Ssms.exe" /dde "%1"
The reason a new instance is always opened with editing seems to be that windows needs to associate the file with a program so that it can identity if the existing program is running and use this instance. This seems to be achieved by using DDE. /dde indicates that the command line should use DDE. "%1" passes the first string (ssms.exe path) to the DDE protocol for usage as a parameter.
DDE Message: was kept at the SSMS 2008 R2's value I found: Open("%1")
DDE Application: Change the Application to ssms.11.0
Why? This was the difficult part. Where is this found? I could not find a tool for displaying the DDE application name. What I found was when I reviewed the registry editor that sqlwb.sql.9.0 is the entry to open a new .sql file with 2008 R2. This matched the registry entry for sqlwb.9.0 that SSMS 2008 R2 entry was showing before I started making my changes in FileTypesMan. I removed the .sql and found that the HKEY_CLASSES_ROOT had an entry for ssms.sql.11.0 .
= File association now set to new installation, and if SSMS.EXE is open, it should use the existing instance with no additional work.
Tip: To further speed up the initial load if you don't have it open, you can use other command line options on the load. Just go to the RUN dialog and type: ssms.exe -? for a list of startup parameters. I personally use -nosplash to eliminate the splash screen load.
Additionally, I use SSMSBoost, the single greatest tool I've had to help with using SSMS daily (basic code formatting, snippet w/cursor placement, preferred connections setup, full keyboard shortcut programming (along with the option for multiple steps in once shortcut, ie basic macros". Andre and his team are extremely responsive to new ideas in their forum, its very much developers helping improve other developer's life.
For SQL 2014 you can use the following *.reg-file (for 2012 replace the 12 with 11 and for 2016 (I guess) with 13) :
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\sql_auto_file]
#=""
"EditFlags"=hex:00,00,00,00
"FriendlyTypeName"="SQL"
[HKEY_CLASSES_ROOT\sql_auto_file\shell]
[HKEY_CLASSES_ROOT\sql_auto_file\shell\open]
[HKEY_CLASSES_ROOT\sql_auto_file\shell\open\command]
#="\"C:\\Program Files\\Microsoft SQL Server\\120\\Tools\\Binn\\ManagementStudio\\Ssms.exe\" /dde \"%1\""
[HKEY_CLASSES_ROOT\sql_auto_file\shell\open\ddeexec]
#="Open(\"%1\")"
[HKEY_CLASSES_ROOT\sql_auto_file\shell\open\ddeexec\Application]
#="ssms.12.0"
[HKEY_CLASSES_ROOT\sql_auto_file\shell\open\ddeexec\Topic]
#="system"
I had this same issue. Using "restore file associations" in ssms 2012 had no effect. I was able to resolve it by right clicking and choosing "open with" -> choose default program. Now I know you've said this didn't work, but there is a trick. Rather than selecting the pre-provided icon for ssms 2012, choose browse and go to c:\program files(x86)\Microsoft SQL server\110\tools\binn\managementStudio\ and click on ssms.exe. Click open, click ok. Once I did this, ssms 2012 was the default, and double clicking more .sql files loads into tabs in the same instance.
Another solution: https://stackoverflow.com/a/24945327/813599
I went looking for a more proper way to link to other Q/A's and couldn't find it after 15 minutes of searching... would love to be educated and will edit this out if so.
I was having a similar but slightly different issue. I wanted to open .sqlplan file in a new tab in SSMS 2014. I tried all of the above but none of them worked.
Looking at the registry, I found that ssms.sql.12.0 has "DdeExec" node, while ssms.sqlplan.12.0 does not.
enter image description here
So I export the "DdeExec" node from ssms.sql.12.0 and rename sql to sqlplan, then import it back in. After that, I was able to open .sqlplan file in a new tab.
Here is the registry file:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\ssms.sqlplan.12.0\Shell\Open\DdeExec]
#="Open(\"%1\")"
[HKEY_CLASSES_ROOT\ssms.sqlplan.12.0\Shell\Open\DdeExec\Application]
#="ssms.12.0"
[HKEY_CLASSES_ROOT\ssms.sqlplan.12.0\Shell\Open\DdeExec\Topic]
#="system"
Management Studio 18:
"C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\Ssms.exe" /dde "%1"
Connect to LocalDB in SSMS
Open Server Properties -> Database Settings
Change Data/Log/Backup locations -> click OK
When I click OK I get this error:
Found some blogpost and changed this in regedit but it didn't help.
Anyone got any other ideas I could try?
I do not believe that these default paths for SQL Server LocalDB are changeable. This is quite unfortunate due to what appears to be a bug with SQL Server Express 2017 LocalDB ** (fixed as of CU 6 for SQL Server 2017), as per this question (and my answer to it) on DBA.StackExchange:
LocalDB v14 creates wrong path for mdf files
HOWEVER, you do not need to use the default paths. Those are used when you create a Database without specifying the physical locations. If you specify the physical location, then you should be able to create the files to any folder / directory that you have read / write access to.
After making that change in the registry try restarting the sql instance.
Also I would make sure that the account running SQL Server has the ability to write to that folder.
for an easy test you could go to the folder properties -> security then add the account 'everyone' then give them full control. then try making that change. If it works it was a permissions issue to that account. Accounts generally don't have access to other users accounts without some level of admin.
After 10 years this is still an issue for the current version(15.0) of Microsoft SQL Server Express.
After a bit of investigation I discovered, there is an issue with permission inside the registry. The process sqlservr.exe cannot create entries in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL15E.LOCALDB\MSSQLServer.
On my computer this process is running under my account, so I opened regedit and gave myself Full Control permission to this key. And it worked like a charm. I hope this will help you as well.
Changing these paths in RegEdit or SSMS doesn't work, SQL LocalDb won't respect these values for existing databases. One has to move the databases manually. Here is the reliable way to change a database location for any LocalDB instance.
First, make sure you work with a correct instance of SQL Server LocalDB. In command prompt enter:
sqllocaldb info
It will show the LocalDB instances you have on your machine. Let's assume that the instance name is MSSQLLocalDB.
Next, execute this script on your database (let's call it TestApp), using SqlCmd tool or SSMS:
alter database TestApp
modify file (name = TestApp, filename = 'C:\NewDataLocation\TestApp.mdf');
go
alter database TestApp
modify file (name = TestApp_log, filename = 'C:\NewDataLocation\TestApp_log.ldf');
go
Now, stop the SQL LocalDB instance, in command prompt:
sqllocaldb stop MSSQLLocalDB
Move the database files to the new location that you specified in the script. From %UserProfile%\TestApp.mdf (which is where they are located) to C:\NewDataLocation\TestApp.mdf, same for LDF file.
Start the SQL LocalDB instance again:
sqllocaldb start MSSQLLocalDB
Now your database is working from a new location. Repeat the steps for any other databases.
Paths Cannot Be Changed in SQL Server LocalDB "Automatic Instance" Types
In case anyone in 2023 finds out they cannot change their default database file storage paths, this article is for you!
This error applies to Microsoft SQL Server not being able to allow you to change the default file folder location on your PC where the SQL Server Database Files are saved (database and logs files, .mdf and .ldf).
Most developers often need control over where local database files are saved. Most prefer to store them in a central location, another drive, or simply the main SQL Server database repository inside the C:\Program Files\Microsoft SQL Server\{sql version name}\MSSQL\DATA, since that is where system data storage goes. One example of the problem of not being able to customize database file storage might be using Entity Framework Core, which runs "migration" scripts that create databases in SQL Server. When it does so, where those scripted databases get stored is heavily dependent on SQL Server's default file path settings. When the location of those EF code-first database files using LocalDB is locked down, developers are stuck with SQL files in multiple locations on their PC's.
THE PROBLEM
Apparently, when Microsoft installs SQL Server / SQL Express on your device, it attempts to install a default instance of the server as a specialized type called a "LocalDB Automatic Instance". They do this to get the user up and running fast with a "LocalDB" sql server instance, which is a one-time, "light", custom created server running as a public instance, complete with default settings which are customized for the user (or developer) so he can get up and running fast. The automatic type has the advantage that its granted permissions to the user as administrator in SQL, as well as granting all applications on the user's device public access to the server instance. (You will notice that IIsExpress works this way using ApplicationPools as dummy Windows User Accounts, creating default accounts next to your User Account in Windows to run app pools in IIS.) These SQL Server LocalDB binaries do not run as a service but on-demand. But only one of the "automatic" types may be installed per version per device. The other SQL Server LocalDB type is the named instance and is not as restricted as the automatic one, apparently.
The problem is, when they create this special LocalDB automatic instance, it locks down certain settings and applies certain permissions and settings that are unique just for this instance. This then limits what the user can do as far as customizations, one of which is the "Database default locations" in the Properties dialog box that appears when you right-click your sql server instance and choose properties.
Anyone using the full SQL Server version, or who has created a new instance of LocalDB, deleting the old one, will not experience this issue, so most of those people are scratching their heads.
But for local developers, what this means is your Sql Server LocalDB databases running under this instance of the server will typically store their databases under a locked down path...either the path you chose on install or default to the user-friendly account paths under C:\Users\{YourName}.
When users attempt to change the path in the properties box for the instance, many users online the past 5-6 years have noticed a nasty RegCreateKeyEx() returned error 5 Access is denied that would appear when saving a default path. Microsoft doesn't bother to tell you, but that is intentional. They don't expect to allow you to save paths to the registry for the instance, and assume everyone is ok with the default path.
You can fix the key error by going into your registry and changing permission on the Microsoft SQL Server registry keys, assigning the "Everyone" group account to the registry node managing these keys. In the Registry, add Everyone group account to this node below then try and save a new default path in the properties box for your sql server localdb instance:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server
The location of the default database file path keys (2019) in the Registry in Windows for an instance of the localdb server of are located here:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL15E.LOCALDB\MSSQLServer
You are then able to save the new default paths in SQL, and the error goes away. Saving your default path in the Properties box works now, and the new values appear in the registry.
Even though you can change these paths, they will not stick, however, and reset back to the User Account Path, by default. Even if you save a new default sql path for your databases, when you create a new database it still reverts to the old path. Again, this applies ONLY for users who are running under the default "Automatic" LocalDB instance created on install of SQL Express.
So even after restarting SQL, restarting your PC, or restarting the SQL Service, those registry values will still not pull the registry keys into the SQL Server instance settings for Default file paths.
As proof, run these two scripts below in your SQL Server LocalDB instance. The first one returns the actual LocalDB default file paths SQL Server stores internally. The second script returns what is stored in your registry for the LocalDB default file path. If you saved new default path registry keys, they should be the same and shown in SQL Server instance properties, but they are different! That means Microsoft has decided not to allow you to change them for those running the "automatic" instance type of LocalDB on install. Below is the T-SQL to run to test this:
-- GETS THE PATH STORED IN SQL SERVER FOR "DefaultData" path
SELECT
[Value] = 'DefaultData',
[Data] = SERVERPROPERTY('InstanceDefaultDataPath')
-- DefaultData C:\Users\YourAccountName\
-- GETS WHATS IN THE REGISTRY FOR "DefaultData" path
EXECUTE [master].dbo.xp_instance_regread
N'HKEY_LOCAL_MACHINE',
N'SOFTWARE\Microsoft\Microsoft SQL Server\MSSQLServer',
N'DefaultData'
-- DefaultData C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA
-- Note: If the second one returns `NULL` it just means you
-- have not yet tried or succeeded in saving a new file path
-- to your registry.
Why isnt SQL Server LocalDB pulling in the registry values?
What this means again, is sorry you can't change these default paths. Your best bet is to simple "detach" your databases, copy the .mdf and .ldf files to your new prefered folder, then reattach. When you create new databases, the console allows you to change the database file path there, as well. There are also some elaborate SQL scripts you can run to set paths before saving files.
But just know this is by design.
I think one of the purposes of LocalDB is that it is very convinient in bundling a demo database along with the source files of an application. The database file and its log, of course, are somewhere in the source file directory.
Take a Visual Studio solution for example, in web.config or app.config, you can see something like this:
<connectionStrings>
<add name="DefaultConnection" connectionString="Data Source=(LocalDb)\v11.0;Initial Catalog=aspnet-XXXXXX-20140609153630;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|\aspnet-XXXXXX-20140609153630.mdf" providerName="System.Data.SqlClient" />
Now that the location of every LocalDB is specified in the config file, I don't think "default location" makes much sense.
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