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.
Related
I have this SSAS running:
I see a database deployed and I am trying to check who deployed it, is there a DMV that I can execute somewhere that can retrieve that information?
I don't believe so, but here's a way you can guess at it!
If you look at the Properties of the server from SSMS, on the General page you can get the DataDir:
Go to this directory on the server. If the user is using the server as their workspace, there will be a folder for their workspace with their lan id:
The Date Modified timestamp on the folder should give you an idea who touched it last.
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.
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 a remote server running SQL Server 9.0.3042, trying to subscribe to a publication on a server running SQL Server 10.0.2531.
These servers are on different domains which basically hate each other and largely refuse to allow their users access to each other.
They do both communicate nicely with a third domain, and it is a user from that domain which I am using as the process owner on both servers.
I have created a shared folder on the publishing server, and I am using it as the Snapshot folder, set via Publication Properties -> Snapshot -> "Put files in the following folder" and have confirmed that the files are being published locally and can be accessed via the shared folder.
The Snapshot Agent on the publishing server runs and appears to complete successfully.
I've then created a Pull subscription on the subscribing server and told it to run with the Agent Process Account of the same user that runs the snapshot agent on the publisher.
I've redirected the snapshot location to "Alternate folder" and set that folder to be the shared folder on the remote server that I set up earlier.
The Pulling server connects correctly to the Publishing server, And then fails because "The process could not read file "\[server].[domain][share][snapshot directory][file].pre" due to OS error 5"
I've logged into the Pull server as the executing account and manually navigated to, and opened, that file. I've done the same on the publishing server.
I'm out of ideas. What am I screwing up?
OS Error 5 is ERROR_ACCESS_DENIED. You're not being allowed to get to the folder. Check to make sure that the user account trying to get to the files has at least read access to the folder containing the files.
The decision has been taken that we're pretty much on the point where we're going to move every user in the company over to a brand new domain, and that this problem isn't worth the time and effort of fixing.
I did find this SO question which relates a similar problem, but I don't intend to investigate this matter any further.
I have an SQL Server database where I have the data and log files stored on an external USB drive. I switch the external drive between my main development machine in my office and my laptop when not in my office. I am trying to use sp_detach_db and sp_attach_db when moving between desktop and laptop machines. I find that this works OK on the desktop - I can detach and reattach the database there no problems. But on the laptop I cannot reattach the database (the database was actually originally created on the laptop and the first detach happened there). When I try to reattach on the laptop I get the following error:
Unable to open the physical file "p:\SQLData\AppManager.mdf". Operating system error 5: "5(error not found)"
I find a lot of references to this error all stating that it is a permissions issue. So I went down this path and made sure that the SQL Server service account has appropriate permissions. I have also created a new database on this same path and been able to succesfully detach and reattach it. So I am confident permissions is not the issue.
Further investigation reveals that I cannot rename, copy or move the data files as Windows thinks they are locked - even when the SQL Server service is stopped. Process Explorer does not show up any process locking the files.
How can I find out what is locking the files and unlock them.
I have verified that the databases do not show up in SSMS - so SQL Server does not still think they exist.
Update 18/09/2008
I have tried all of the suggested answers to date with no success. However trying these suggestions has helped to clarify the situation. I can verify the following:
I can successfully detach and reattach the database only when the external drive is attached to the server that a copy of the database is restored to - effectively the server where the database is "created" - lets call this the "Source Server".
I can move, copy or rename the data and log files, after detaching the database, while the external drive is still attached to the Source Server.
As soon as I move the external drive to another machine the data and log files are "locked", although the 2 tools that I have tried - Process Explorer and Unlocker, both find no locking handles attached to the files.
NB. After detaching the database I tried both stopping the SQL Server service and shutting down the Source Server prior to moving the external drive - still with no success.
So at this stage all that I can do to move data between desktop and laptop is to make a backup of the data onto the external drive, move the external drive, restore the data from the backup. Works OK but takes a bit more time as the database is a reasonable size (1gb). Anyway this is the only choice I have at this stage even though I was trying to avoid having to go down this path.
Crazy as it sounds, did you try manually granting yourself perms on the files via right-click / properties / security? I think SQL Server 2005 will set permissions on a detached file exclusively to the principal that did the detach (maybe your account, maybe the account under which the SQL Server service runs) and no-one else can manipulate the file. To get around this I have had to manually grant myself file permissions on MDF and LDF files before moving or deleting them. See also blog post at onupdatecascade.com
Can you copy the files? I'd be curious to know if you can copy the files to your laptop and then attach them there. I would guess it is some kind of permissions error also, but it sounds like you've done the work to fix this.
Are there any attributes on the file?
Update: If you can't copy the files then something must be locking them. I would check out Unlocker which I haven't tried but sounds like a good starting point. You might also try taking ownership of the files under the file permissions.
When you are in Enterprise Manager or SSMS, can you see the name of the database that you are talking about? There might be a leftover database in a funky state. I'd make sure that you have a backup or a copy of the mdf somewhere safe. If this is the case, maybe try dropping the database and then re-attaching it.
I would try backing up the database on the desktop, and then see if it will restore successfully on the laptop. Doesn't explain your issue but at least you can move forward.
Run sqlservr.exe in debug mode with the /c switch and see what happens starting up. Any locking or permissions issue can be put to bed by making a copy of the file and transfering the copy to the origional.
Also check the associated log file (.ldf) .. If that file is missing or unavaliable you will not be able to mount the database to any sane/consistant state without resorting to emergency bypass mode.
I've had a similar issue. Nothing seemed to resolve it - even tried to reboot the machine completely, restarting SQL services etc. ProcMon and ProcessExplorer were showing nothing so I figured - the "lock" is done by OS.
I resolved it by DELETING the file and restoring it back from the drive mounted under another drive letter.
PS. My database file was not on a USB drive, but on a TrueCrypt-drive (in some you can say it's a "removable drive" as well)
Within SQL Server Configuration Manager, look in SQL Server Services. For all your SQL Server instances, look at which account is selected in the Log On Tab - Log On As:. I've found for instance, changing it to the Local System account resolves the issue you've had. It was the only thing that actually worked for me - and certainly, no shortage of people have had the same problem.
It's a security issue on -file level security - you have detached db with different credential and attaching it with other credential - just browse the article http://www.sqlservermanagementstudio.net/2013/12/troubleshooting-with-attaching-and.html
And try copy pasting it to different location.
I solved similar issue by granting system administrator to all permissions:
right click > properties
security tab
in group or usernames click edit.
click add > advanced
click find now to list all available permissions.
choose administrator and add it to list.
grant it to has full permission.
I had the same issue. Someone had detached the files and left, and we were unable to move it to another drive. But after taking ownership of the file (security-->advanced-->take ownership to your login id), and then adding your login id to the security tab and giving access on the file, was able to move.