I'm trying to run a Maintenance Cleanup Task to remove .bak files older than 2 days (simple enough).
Been trying all variety of .bak, BAK, .*., and editing the path, but the files are still not getting removed even though I receive a "job succeeded" log message.
I'm at the point where I believe it's a folder permission issue.
How do I make sure my SA has the proper permissions to remove files from a folder?
T-SQL:
EXECUTE master.dbo.xp_delete_file 0,N'D:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Backup\',N'BAK',N'2012-06-21T11:35:59',1
Thanks.
I always have domain account with some (in your case sa) privilages on sql server. Then you add domain login to folder.
Related
While doing replication I received the following error message in Replication monitor → Agents
Access to the path 'D:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\repldata\unc\_DEMO_SAMPLE\20160602154451\' is denied.
If the folder is manually created, then the error is solved for some time. However, after some time the error occurs again because the timestamp (20160602154451) has changed. How can I create a folder dynamically? Or can anyone suggest another solution to this problem?
When installing sql server I always make the UNC folder a shared folder.
You either make it RW available to everyone, not big deal for security.
Or identify the network login on which the replication agent is using and give it modify access to that folder.
This login was set during the sql server install.
i want to run exe file from stored procedure. But, output is 'Access is denied'.
how can i do? my sql query is as the following. It is just testing query
EXEC master..xp_CMDShell 'C:\Users\myo.minlin\Downloads\Firefox Setup Stub 33.1.1.exe'
The reason is because your SQL-Server process runs, if not specified other, not with your myo.minlin account. The account which started the process does not have permissions on the file you provided. This is good so, because the database should not be able to access your private files. There are three or even more possible solutions:
Move the file to a location where the SQL-Server has access to.
Make sure that the account on which the SQL-Server is running has the right permissions to execute your file
Launch the SQL Server process with the myo.milin account.
I do not reccommend solution 3. Solution 2 is also not reccommended if the file is in your home directory.
See Configure Windows Service Accounts and Permissions.
I have a windows form application that requires users to log in to access the information. I have created a local compact database file for the credentials to be stored. I added the database file to my the folder but when I open my application and try to log in it tells me that it cannot find the database file.
Should the file be stored on a different folder, or should I need to install an instance of sql on the user computer.
This is my first deployment so I am not sure how to go about it. I have done some research on the subject, but it does not seem related to my issue. The help section of Intallshield was not clear either.
I am looking for some resources on how to accomplish this.
I figure out the issue, in order to work all files, including the database files need to be dumped under the userprofile folder.
I'm trying to go through multiple .trc files to find out who has been logging into SQL Server over the last few months. I didn't setup the trace, but what I've got are a bunch of .trc files,
ex:
C:\SQLAuditFile2012322132923.trc,
C:\SQLAuditFile201232131931.trc
etc.
I can load these files into SQL Profiler and look at them individually, but I was hoping for a way to load them all up, so that I can quickly scan them for logins. Either using a filter, or better yet, load them into a SQL Server table and query them.
I tried loading the files into a table using:
use <databasename>
GO
SELECT * INTO trc_table
FROM ::fn_trace_gettable('C:\SQLAuditFile2012322132923.trc', 10);
GO
But when I do this, i get the error message:
File 'C:\SQLAuditFile2012322132923.trc' either does not exist or is not a recognizable trace file. Or there was an error opening the file.
However, I know the file exists, and I have the correct name. Also they appear to be recognizable because I can load them up into SQL Profiler and view them fine.
Anybody have an idea why I'm getting this error message, and if this won't work, perhaps another way of analyzing these multiple .trc files more easily?
Thanks!
You may be having permissions issues on the root of C:. Try placing the file into a subfolder, e.g. c:\tracefiles\, and ensuring that the SQL Server account has at least explicit read permissions on that folder.
Also try starting simpler, e.g.
SELECT * FROM ::fn_trace_gettable('C:\SQLAuditFile2012322132923.trc', default);
Anyway unless you were explicitly capturing successful login events, I don't know that these trace files are going to contain the information you're looking for... this isn't something SQL Server tracks by default.
I had pretty much the same issue and thought I'd copy my solution from
Database Administrators.
I ran an SQL trace on a remote server and transferred the trace files to a
local directory on my workstation so that I load the data into a table on my
local SQL Server instance for running queries against.
At first I thought the error might be related permission but I ruled this
out since I had no problem loading the .trc files directly into SQL Profiler
or as a file into SSMS.
After trying a few other ideas, I thought about it a bit more and realised
that it was due to permissions after all: the query was being run by the SQL
Server process (sqlsrvr.exe) as the user NT AUTHORITY\NETWORK SERVICE –
not my own Windows account.
The solution was to grant Read and Execute permissions to NETWORK
SERVICE on the directory that the trace files were stored in and the trace
files themselves.
You can do this by right-clicking on the directory, go to the Security
tab, add NETWORK SERVICE as a user and then select Read & Execute for
its Permissions (this should automatically also select Read and
List folder contents). These file permissions (ACLs) should automatically
propagate to the directory contents.
If you prefer to use the command line, you can grant the necessary permissions to
the directory – and its contents – by running the following:
icacls C:\Users\anthony\Documents\SQL_traces /t /grant "Network Service:(RX)"
I have to sync some folders from a linux server, to another.
We have created the RSA-Key and the authentication goes well.
When we launch an rsync command, some of the files gave birth to errors like:
rsync: readlink "/var/www/sestantemultimedia.it/xxecommerce/pub/.htaccess" failed: Permission denied (13)
Now, the directory /var/ (as well as other subdirectory) have the permits set to 755.
The files into the last directories have permits set like 644.
So, theoretically, permits as set right and I can read from the other server and copy my files.
What I am missing?
Ok, I just figured it out.
Someone (because we work together as a team) had done a change on the "final folder" so that "apache" user's group can't execute (so can't traverse) the folder itself.
In that way, although it is possibile for "other group" to execute, the sum of permits that we receive (we were into "apache" group) isn't enough for "execute" the folder and retrive the file.
We just change that scenario and now it works properly!