I have a network folder and two machine accounts, node1$ and node2$, both of them having full control permission on the folder.
I log in a SQL Server instance in the node1 machine and back up a SQL Server certificate on the network folder, which generates a crt and a pvk files.
Then I log in node2 machine and try to restore the certificate in another SQL Server instance. But I can't because node2$ has no permissions on the requested files .crt and .pvk.
Even more, if I check the created files, the very node$1 machine account has no explicit permissions on these files. Instead, I find an "owner rights" ACE.
So, the files don't seem to inherit the permissions that node1$ and node2$ have on the folder.
This issue doesn't occur with other kind of files.
I can solve this by manually assigning explicit permissions on the files to node2$.
But my question is: why .crt and .pvk files don't inherit the permissions as other types of file do?
The documentation explains it:
When performing a backup, the files will be ACLd to the service account of the SQL Server instance. If you need to restore the certificate to a server running under a different account, you will need to adjust the permissions on the files so that they are able to be read by the new account.
As you already figured out: inheritance is disabled because the T-SQL command BACKUP CERTIFICATE explicitly removes all permissions but for the service account.
I'm writing a WPF .NET application (fwk 4.0) which references log4Net and must be installed in the 'Program Files(x86)' directory on a Windows 7/8/10 64bits OS.
The application logs created by the application are .txt files created in the installation sub-directory of the 'Program Files(x86)'
This application also uses on the SQL Server CE 4.0 in the same subdirectory.
C:\Program Files(x86)\MYAPP\APP1\APP1.txt
C:\Program Files(x86)\MYAPP\APP1\CEDatabase.sdf
The application is installed by a local administrator.
To start the application, a standard user is prompted by UAC to start with an elevated acess token (admin privileges) to run the application because it won't start otherwise (I think ACL not granted to create and write logs).
The WPF application build holds no application manifest.
My client is frustrated by the fact that a standard user can not start the application without the UAC elevation. Moreover, it wants to keep on installing in the 'Program Files (x86)'.
What can I do to manage this situation?
I'd strongly suggest not writing the log files to the same location as you install your application, but instead to one of the standard public locations, which you can access by environment variables.
See this link for more details on how to set this in Log4Net : How to specify common application data folder for log4net?
The two common locations to log to which avoid UAC restrictions are:
CommonApplicationData (https://msdn.microsoft.com/en-us/library/windows/desktop/aa367992(v=vs.85).aspx) which is a location where all users can write to, so you might want to use this if you want a common logging location regardless of who is logged on to Windows and running your application.
LocalAppData (https://msdn.microsoft.com/en-us/library/windows/desktop/aa369768(v=vs.85).aspx) which is a location specified to your currently logged on user. This would allow you to keep your log files from different Windows users separate from each other.
I'm not sure off the top of my head whether you'd have the same issue with writes to the SQL Server CE database. The pattern I've followed in the past to work with UAC is to install all static files under Program Files, then all data under one of the above 2 mentioned folders depending on whether the application data and logging was per-user or per-installation.
I need to copy my SQL Server DBs to a folder. The files are attached to SQL Server, which I have detached using my code. When I try to copy these files using
My.Computer.FileSystem.CopyFile(filePathToCopyFrom1, targetFilePath1)
It returns error:
"Access to the folder D:\MyDbs is denied"
When I manually coped these files, it asked "You need Administror permission to copy these files" I clicked continue and it worked but how to fix this using my vb.net code?
I have given Full Control to administrator from Windows but still it did not work.
Thanks
Seems that the detaching process went well. You can copy through windows explorer, but not from you application. The key difference here is that the files are protected to be accessed by the administrator user only.
Then, you need to run your application using an administrator windows account so that the application inherits the permissions of the user to be able to perform this operation.
Remember, if you are using Windows Vista+ (which I assume you do) the root folder is almost off limits. You can run the App as Administrator, or copy it to a folder in the root. The other point is that where you copy from. If the DB is currently in Program files, it is very possible that you will get this problem as well, and then you will have to run the application as Administrator.
Right click on the application, and select Run as Administrator, or select properties and in Compatibility check the box that the program should be running as Administrator. If you use the latter, then a box will pop up every time you run it, unless you change the User Account Control settings.
I used the following the script to attach a database. But the database created is read only.
What modifications should I make in the script to make it read-write. Please help me.
USE [master]
GO
CREATE DATABASE [GemDatabase] ON
( FILENAME = N'E:\Program Files (x86)\ICE Products\ICEConnect200\New Database\GemDatabase.mdf' ),
( FILENAME = N'E:\Program Files (x86)\ICE Products\ICEConnect200\New Database\GemDatabase_log.ldf' )
FOR ATTACH
GO
if not exists (select name from master.sys.databases sd where name = N'GemDatabase' and SUSER_SNAME(sd.owner_sid) = SUSER_SNAME() ) EXEC [GemDatabase].dbo.sp_changedbowner #loginame=N'sa', #map=false
GO
First make sure that the folder in which your .mdf file resides is not read only.
If it is, un-check that option and make sure it reflects to folders and files within that folder.
Once that is done, Open Management Studio, in the Object Explorer right click on the Database which is read only and select Properties. In the Options Menu, check that the Read-Only property is false.
Giving the sql service account 'NT SERVICE\MSSQLSERVER' "Full Control" of the database files
If you have access to the server files/folders you can try this solution that worked for me:
SQL Server 2012 on Windows Server 2008 R2
Right click the database (mdf/ldf) file or folder and select "Properties".
Select "Security" tab and click the "Edit" button.
Click the "Add" button.
Enter the object name to select as 'NT SERVICE\MSSQLSERVER' and click "Check Names" button.
Select the MSSQLSERVER (RDN) and click the "OK" button twice.
Give this service account "Full control" to the file or folder.
Back in SSMS, right click the database and select "Properties".
Under "Options", scroll down to the "State" section and change "Database Read-Only" from "True" to "False".
ALTER DATABASE [DatabaseName] SET READ_WRITE
Make sure the files are writeable (not read-only), and that your user has write permissions on them.
Also, on most recent systems, the Program Files directory is read-only. Try to place the files in another directory.
Open database properties --> options and set Database read-only to False.
Make sure you logged into the SQL Management Studio using Windows Authentication.
Make sure your user has write access to the directory of the mdf and log files.
Did the trick for me...
You need to change permission for your database folder: properties -> security tab -> edit... -> add... -> username "NT Service\MSSQL$SQLEXPRESS" or "NT Service\MSSQLSERVER". Close the windows, open Advanced..., double click the user and set as follows:
Type: Allow
Applies to: This folder, subfolder and files
Basic permissions: all
Make sure the owner is set too.
Another Way which worked for me is:
After dettaching before you attach
-> go to the .mdf file
-> right click & select properties on the file
-> security tab
-> Check Group or usernames:
for your name\account (optional)
and for "NT SERVICE\MSSQLSERVER"(NB)
List item
-> if not there than click on edit button
-> click on add button
and enter\search NT SERVICE\MSSQLSERVER
-> click on OK
-> give full rights
-> apply then ok
then ok again
do this for .ldf file too.
then attach
If SQL Server Service is running as Local System, than make sure that the folder containing databases should have FULL CONTROL PERMISSION for the Local System account.
This worked for me.
You need to go to the new folder properties > security tab, and give permissions to the SQL user that has rights on the DATA folder from the SQL server installation folder.
There are 3 (at least) parts to this.
Part 1: As everyone else suggested...Ensure the folder and containing files are not read only. You will read about a phantom bug in windows where you remove read only from folders and containing items, only to open the properties again and see it still clicked. This is not a bug. Honestly, its a feature. You see back in the early days. The System and Read Only attributes had specific meanings. Now that windows has evolved and uses a different file system these attributes no longer make sense on folders. So they have been "repurposed" as a marker for the OS to identify folders that have special meaning or customisations (and as such contain the desktop.ini file). Folders such as those containing fonts or special icons and customisations etc. So even though this attribute is still turned on, it doesn't affect the files within them. So it can be ignored once you have turned it off the first time.
Part 2: Again, as others have suggested, right click the database, and properties, find options, ensure that the read only property is set to false. You generally wont be able to change this manually anyway unless you are lucky. But before you go searching for magic commands (sql or powershell), take a look at part 3.
Part 3: Check the permissions on the folder. Ensure your SQL Server user has full access to it. In most cases this user for a default installation is either MSSQLSERVER or MSSQLEXPRESS with "NT Service" prefixed. You'll find them in the security\logins section of the database. Open the properties of the folder, go to the security tab, and add that user to the list.
In all 3 cases you may (or may not) have to detach and reattach to see the read only status removed.
If I find a situation where these 3 solutions don't work for me, and I find another alternative, I will add it here in time. Hope this helps.
If you have tried all of this and still no luck, try the detach/attach again.
Here is what worked for me (OS 2016/SQL 2016):
First I ensured that the source and destination SQL had the same version/build.
Log into the server as an administrator:
a. Make sure that the SQL Service account has read, write, execute permissions on the files you want to attach. For me, I noticed that permission-inheritance was disabled, so I re-enabled inheritance and ensured the service account had the correct permissions.
b. Open SSMS on the server and re-run your CREATE DATABASE statement.
just open new query and write this:
alter database [your database] set read_write
The procedure is simple to avoid locking db with read-only atribute:
Detach database
Move the files mdf and ldf to the new location on your computer
Right click on mdf and ldf files (in turn, for each file), Properties, Security Tab, for the ComputerName User check full control. Apply, OK.
Attach database from your new location you put the files
Answer from Varun Rathore is OK but you must consider that starting from Windows Server 2008 R2 and higher the SQLServer service will run under a local virtual account and not anymore under the old well known "NETWORK SERVICE".
Due to this, to switch a newly attached DB to "not read only mode", you must setup permissions on the ldf and mdf files for local machine user line "NT SERVICE\MSSQLSERVER" where MSSQLSERVER would be the service name in a pretty standard installation.
Checkout this https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/configure-windows-service-accounts-and-permissions#VA_Desc for details configuring service permissions
I am trying to automate the Account Creation process in Active Directory and I want to create the user home directory on a server and then I want it to become a shared folder with some user permissions.
I can create folder on that machine (remote machine) but I cannot convert it to a shared folder. Is there a way I can do that. Note I can create shared folder locally and can set permissions but cannot do that when the machine is different.
Which language are you using to script ?
You can do exactly what you are doing localy, on a remote computer using psExec from SysInternals. You'll find at th end of this post how to do it in ldap mixed in with WMI.