I have an SSIS package that pulls some data out of SQL Server into a .csv file, then copies the file to a network location (uses Robocopy). Runs fine as a SQL Agent job. When I use DtExec from my own machine, Robocopy fails with 'Access is denied.'
The same error occurs regardless of which network location I enter. If I use Robocopy to try to copy to a local drive on the server instead, it works fine. DtExec is running as my own account. If I use remote desktop to login to the server (again with my own account) I can access all the network shares, and run Robocopy directly no problem. I am using UNC names throughout - no drive letters anywhere.
Is it possible DtExec is running under some low-privilege account on the server that cannot access any network resources? If so, any ideas on how to work around it?
Related
I need to connect to a remote database (Oracle) using a MS SQL Server (2019) linked server. What I did so far:
Installed Oracle Instant Client x64 and the ODBC drivers on the machine where the SQL server is running
Created a symlink to the central TNSNAMES.ORA (on a file share in the network) inside the Oracle Instant client folder.
Set the necessary environment variables
Created an ODBC connection to the database on the Oracle server on this machine
Restarted MS SQL Server
Created a linked server (Microsoft OLEDB Provider for ODBC Drivers) in the SQL instance
When connecting to the SQL Server using sqlcmd on this machine (I did not install SSMS there), I can query the linked database using OPENQUERY(). I can also read the file TNSNAMES.ORA using this command (note, the given file is the symlink, but it displays the contents of the linked file, as it should):
SELECT * FROM OPENROWSET(BULK 'C:\InstantClientx64\tnsnames.ora', SINGLE_CLOB) TNSNames
So far, everything is fine.
Now, when I connect to the SQL Server from my workstation using SSMS, i get the following error when trying to read TNSNAMES.ORA using the command above:
Cannot bulk load because the file "C:\InstantClientx64\tnsnames.ora" could not be opened. Operating system error code 5(Access is denied.).
I created a file test.txt in the instant client folder containing something like "Am I allowed to read this?" - and I was, no problems.
I started procmon on the server to find out what happens. When using the above command on the SQL server, I get a REPARSE (because it's a link!), and then SUCCESS, the file is displayed in the sqlcmd console.
When using this command in SSMS (on my local workstation), first appears the REPARSE (OK), then ACCESS DENIED.
In both cases it is the same user account which is displayed as "Impersonating" in the procmon's details. There is definitely no problem with a firewall, and the read permissions on the tnsnames.ora file on the network share are granted for Everyone. I am also able to create an ODBC item on the local workstation, and can connect and query the database from here.
I have done this in the past I don't know how often, and never had problems. What am I missing?
Why are you trying to read the tnsnames.ora file via SQL? The Oracle libraries will (should) internally open it and use it when your app connects to the DB.
The default location for network config files is shown in the Instant Client installation doc. In your case it will be C:\InstantClientx64\network\admin. Unless you have set the TNS_ADMIN variable, then start by creating this subdirectory and putting tnsnames.ora in it.
(A future version of Instant Client on Windows will create the network\admin subdirectory automatically, similar to the way it is created with the Linux Instant Client packages).
I'm made a QT application that creates a .csv file on a network drive, connects to a MS SQL DB via an ODBC connection, and then executes a BULK INSERT. The problem is that when the program executes the query using a login, it fails with:
[Microsoft][ODBC SQL Server Driver][SQL Server]Cannot bulk load because the file "\10.10.10.10\data\myCSV.csv" could not be opened. Operating system error code 58(The specified server cannot perform the requested operation.).
I need to be able to run this program from a remote computer, and specify a network path for the BULK INSERT statement. There must be some sort of permissioning that's not allowing ODBC SQL SERVER login to access network/UNC paths. What is it? What am I missing? I've tried giving the network path permissions to read from everyone and a host of other things.
Here are some test cases I've done and their results:
If I run the application on the same machine, using "TRUSTED_CONNECTION", everything works as expected regardless of file location.
If I run the application on the same machine, using a login, and a network path, I get the above error. If I use a local path (C:\ for instance), everything works as expected.
If I run the application remotely, I have to use a login, and the program fails with the above error.
Explicitly give the AD account the SQL Server Service is running under access to the share
"is this a required step to get this to work" To authenicate to a different host? Completely.
Thank you to #Larnu for the answer, this solved it
My SSIS package uses Script Task which calls File.Exists() to determine if file is present.
I have to servers on same domain, e.g. THISDOMAIN, SERVER1 and SERVER2
I have user THISDOMAIN\ADMIN which is on both servers.
SERVER1 needs to access SERVER2 folder C:\ which is mapped to SERVER1 as D:\
On SERVER1 there is SQL Server 2008R2 which has SQL Server Agent with Account THISDOMAIN\ADMIN
If I log on to SSIS on SERVER1 with windows authentication as THISDOMAIN\ADMIN package executes successfully.
But if I execute the same package with SQL Server Agent, it does not see the network drive D:\ on 'SERVER1`
What I tried:
Why wouldn't SSIS package running in SQL Server Agent job transfer files to a network folder?
How do I create a step in my SQL Server Agent Job which will run my SSIS package?
When going across the network to access files/folders, it's always recommended to use the UNC path.
Especially in a situation like this where the drive may be mapped via Windows Explorer and works when you're logged in, but doesn't work when you're trying to access that same path from a service that isn't logged in.
My machine is a macbook pro. However, my company's data is in SQL Server. In order to access it, I need to use VMWare Fusion to run SQL Server Management Studio 2008 on Windows XP.
When I attempt to run a bulk import (via instructions from SQLAuthority.com), I get this error:
Msg 4861, Level 16, State 1, Line 1
Cannot bulk load because the file "H:\test.CSV" could not be opened. Operating system error code 3(The system cannot find the path specified.).
I am dealing with 3 different file locations, but none of them work.
My Mac storage - "/Users/Admin/Documents/test.CSV"
My Windows XP storage - My "C:" drive. "C:\test.CSV"
My company's network location - Mapped to the "H:" drive via Windows XP. "H:\test.CSV"
Changing the script to point to all these locations provides the same error message.
Any thoughts on how to overcome this? Presently, my only alternative is to use the SQL Server Import/Export tool, but it takes a while to setup every import. Script is faster.
A bulk insert runs from the server. So it can't reach your local disk.
The server uses the account that the "SQL Server" Windows service uses. That account typically does not have any mapped drives.
Try using a full name, like:
\\server\share\test.csv
Possible other solutions:
Ask a DBA to open a share on the server for imports
Ask a DBA to place the CSV file on a disk on the server
Ask the DBA which account is used for the SQL Server service. If it's a domain account, you can give the account read rights on a network share.
I experienced this error, too.
In my case the solution was to change the path in T-SQL from a share to the actual directory: \\server\share$\file -> drive:\folder\file.
The culprit ended up being a problem with VMWare, which caused the server to have trouble authenticating with some network shares.
I’m trying to backup a SQL08 database to a target on a remote drive and keep ending up with error reason “1815”. This happens either when scripting the backup or using the task wizard GUI. It also occurs when attempting to use either UNC or a shared drive letter to the same path. Another machine on the network doesn’t have a problem backing up to the same path. The network location has write access open to all. Any ideas?
BTW, the successful machine is a server 2008 VPC running on Vista while the one failing is just running directly on an XP host.
check the write access to the UNC for the service account that sql server runs under.
I think you've an existing backup rename it and execute again