I am creating directories with xp_cmdshell but I can't delete them after because of the permission, I am not even allowed to see the owner of the folders.
I have to enter in safe mode to be able of delete the folders.
I am using SQL Server 2008.
Danger, Will Robinson, Danger!
This sounds like it might not be ideal from several angles - security, future-proofing, and scalability. Assuming none of those are priorities for your code, crack on with Edgard's answer.
Otherwise, I would question any design that has the DBMS (directly) write folders in the file system. I don't question that you have your reasons, it's just that there are some very big, but very non-obvious risks that won't bite you until later when you're already committed to the course. There may be less risky and more straightforward ways to do whatever you're doing.
I'm assuming it's an ACL problem.
A directory created with xp_cmdshell is owned by SQL Server (The service account) and its access rights are inherited from the parent.
If you have to modify the directory's content after its creation, you'll have to :
Create your directory inside another one who already have good access rights.
Or grant more rights after its creation (with xp_cmdshell and icacls to manipulate the ACLs)
Eg, change domain\group & d:\folder_path in the following snippet to whatever suits you to give a group (your users, admins, etc...) full control on a directory :
exec xp_cmdshell 'icacls "d:\folder_path" /grant "domain\group":(f)'
Related
I have a shared accde file on a network drive. Occasionally we will have an inconsistent state problem. The error message appears below. It seems to be associated with network connection interruptions for even one user. We have an example when a user unplugged the Ethernet and switched automatically to wireless and other examples where users have left the database open overnight, perhaps when a machine hibernates.
Once this happens the one user cannot work and no one can open the accde file. Other users who have the database open can continue to work.
After the problem occurs it remains until everyone closes the database. At that time it completes whatever recovery it requires and all users can get back in.
This was disruptive when we had six users in one room. Now we have 17 in two cities and a few work-from-home users. It's becoming intolerable.
The obvious answer is to move away from Access. We're working on it but it's a long way off. In the mean time I would appreciate any advice.
Is there a way to prevent the problem entirely?
Is there a VBA way to detect the problem in the instances that are not showing the error message?
Is there something I'm not thinking of?
What would you do?
Error message:
Microsoft Access has detected that this database is in an inconsistent state, and will attempt to recover the database. During this process, a backup copy of the database will be made and all recovered objects will be placed in a new database. Access with then open the new database. The names of objects that were not successfully recovered will be logged in the "Recovery Error" table.
The solution that Microsoft gives is Splitting the database, which just means to put the data elements on a shared server, and everyone has their own copy of the front end.
This might cause problems if that front end needs to be updated (e.g. additional forms). Details here:
http://answers.microsoft.com/en-us/office/forum/office_2007-access/microsoft-office-has-detected-that-this-database/3fb41c70-f7ba-41dd-a847-e62203071466?auth=1
Check the row count in the tables, the tables most likely have large amounts of data creating latency on the read and write queries, causing the locking.
Archive older data and keep the database small and neat, perhaps create referenced databases for archived information
I gather that your MS Access database is getting corrupt when up put it on a shared drive. A Microsoft Access database may get corrupt when in a multi- user environment. Here are the workaround that you can use in order to fix it.
Step 1: Run Command Prompt as Administrator
Click on the Windows icon and type Command Prompt. Then right-click on the Command Prompt and choose Run as administrator option.
Step 2: Execute Compact and Repair Database Command
In the command prompt window, type the following command and then press ‘Enter’.
msaccess <database file name> /compact
In the command, replace <database filename> with database path. For instance,
msaccess "C:\Program Files\Reports.mdb" /compact
This will start the process to compact and repair the faulty Access database file.
Otherwise, You can check out this thread for an alternative solution : https://dba.stackexchange.com/questions/71906/ms-access-mdb-ldb-database-corrupted/171275#171275
So, there used to be a very useful article explaining windows 2008 r2 uac and permissions here http://blog.akinstech.com/understanding-windows-7-and-2008-r2-uac-and-permissions/
This explains why even though you are logged on as a domain admin you still can't do anything because of the two tokens yada yada.
I kick myself since I didn't make a copy of the article
But his method to allow domain admins to use files with full permissions was to create a local group called F_FileAdmin and then use icacls to grant that group full rights to the C:\ and then add domain admins to that group. I thought it was a pretty elegant approach.
So, anyone know the icacls syntax off hand to accomplish this? And or can pull up the article from some cache somewhere and or contact Mr. akinstech and ask him to put this very useful article back online :)
A-Ha! I did save it. I realize I'm a year to late here, but maybe someone else can use it.
Create a group called F_FileAdmin and add the users you want to it.
icacls D:\ /grant "F_FileAdmin":(OI)(CI)F /T
This will add the “F_FileAdmin” group to the entire D: drive and propogate the permissions down to all subfolders and files, ensuring you have access.
Stick this batch file in your scripts directory such that it is in your path. Now on any server, from an elevated command prompt, you can provision a folder by simply typing:
setfileadmin d:\SharedData
setfileadmin e:\
setfileadmin "f:\Accounting Files"
Or even use it remotely like this…
setfileadmin \\MyServer\d$\GroupData
In SQL Server 2008 I can attach databases located only in its predefined folder (C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA). On may occasions, especially when I read a book, I need to attach test database from desktop rather then copy each database every time I need it, but SQL Server does not allow me to access desktop.
Any workaround to solve this issue?
It's probably a matter of granting the account running the SQL service appropriate permissions to your desktop folder (C:\Documents and Settings\YourLogin\Desktop). But, rather than use a location like Desktop that is specific to your login and possibly inaccessible to the account running the SQL service, why not use a common holding location for these files? Something like C:\AdHocDBs or whatever you want to call it.
When a database file (data or log) is first created, it is (of course) located in a specific drive and folder. When a backup is created, this information is stored as part of the backup. A database RESTORE command will assume that the database is to be restored in the exact same location, unless instructed otherwise. To do this, in the RESTORE command under the "with" option, you must include the "move" option. It looks something like this:
RESTORE ...
with
move '<logcalFileName>' to 'physicalFileName'
,move '<logcalLogFileName>' to 'physicalLogFileName'
One move must be included for each file to be so moved, so you usually end up with at least two of these clauses. The tricky part is that you must know the database files' logical names. These can be found via sp_helpFile on an attached database, and
RESTORE FILELISTONLY
from disk = '<backupFile>'
On an existing backup.
(I'm sure all this can be done somehow with the SSMS backup/restore GUIs. I switched over to TSQL-based scripts years ago, to provide quick and flexible access to all the features wrapped in the backup and restore commands.)
I'm working on a web interface for modifying Oracle database backup settings. One of the options I want to give users is where to set the flash recovery area. As far as I know, the only way to change this is by executing something like:
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='C:\file\path' SCOPE=BOTH SID='*';
The problem is that if the file path is some path that doesn't already exist on the system, it isn't created automatically, and this script fails. Does anyone know if there is a way to instruct Oracle to make that directory for me or if there is a PL/SQL script I can use to create a directory on the physical disk (I.E. not a CREATE DIRECTORY call)?
If you really want to do this, write a Java stored procedure (stored as an Oracle object) that calls the mkdir function on a file object. You'll need to use dbms_java.grant_permission to grant java.io.FilePermission privileges.
For SQL Server 2008 Developer Edition on Vista 64 bit:
I tried copying a database using a Vista admin account using the attach/detach method and it failed due to a file permission error so I gave the user that sql services are running as write and modify to the directory. The copy didn't work. I then gave it full control. The copy worked.
Does that make sense?
If I revoke full control from the user, will that cause problems?
The weird thing is that in an existing working database with files in a different directory, there are no special permissions on the directory and files for the database, so why does a copy require full control?
When you detach a DB, the MDF/LDF files may be set with more restricted perms than you expect, like exclusive to the principal that did the detach - maybe the SQL Server service account or the domain account of the user that performed the detach. I have in the past had to manually add back permissions on the files' Properties > Security tab for other users, or else the files act as if they are locked. See also http://www.onupdatecascade.com/2009/07/sql-server-locks-mdf-and-ldf-files-upon.html
also: http://msdn.microsoft.com/en-us/library/ms189128.aspx
( thanks GrumpyOldDBA )
If the server and/or data you are working on does not require those restrictive permissions to be set, you can set a startup flag in SQL Server that will override this function. I understand what Microsoft is going for with this - they assume if you detach a DB they don't want just anyone to walk away with the file; however, I think keeping a good hacker from doing that is easier said than done, and encrypting the DB is the best method for safeguarding data.
Anyway, there is a "Trace Flag 1802" which is oddly named, since it's nothing to do with tracing. You'll want to add it to your SQL startup in SQL Configuration Manager if you want to keep this behavior.
https://support.microsoft.com/en-us/kb/922804
I myself had the same issue and found the answer in StackExchange:
https://dba.stackexchange.com/a/77683/11001