I am having trouble moving a folder from an online drive, Drive :Z\zfilepath
to my local drive, Drive C:\cfilepath
So far, I have one 'file system task' that can copy a file from a source and move it to a destination.
I have correctly specified both filepaths and folder names into the task.
When I run the package, I get the following error:
[File System Task] Error: An error occurred with the following error message: "Access to the path ':Z\zfilepath' is denied.".
Is there some way for me to set up the package such that it will have the credentials to access the online :Z\ drive and run the task?
Z is likely a mapped drive. A drive is mapped per user account so the probable error is that the account that runs SQL Agent (or the credentialed user running a task) does not have that same drive mapped.
One maps a drive from the command line (Execute process task) with the following syntax
net use z: \\server\share PasswordInClearTextHere /user:domain\user /persistent:yes
I don't know enough about your environment. Maybe a one-time activity of mapping the drive will suffice /persistent:yes.
We had an issue where we always had to re-establish the mount when the job ran but we couldn't be certain the previous job succeeded (which had a final step of tear down the mount). Attempting to mount a drive when one already exists will throw an error so you might need another Execute Process Task to delete a mapped drive if it already exists. We ended up with a batch script that would check to see if the mount existed. If it did, it would delete it first. Then it established the mount.
This batch script approach allowed the DBAs to secure the file with file system permissions. The job could access the batch script but we could not so they didn't have to worry about us having access to yet-another-account.
The other, far simpler approach is to not deal with mounting drives and instead just use the UNC path. Assuming you don't have to worry about presenting different credentials than the current user, it makes life much easier.
\\server\share\MyFile.123.txt
A service running under domain account starts 20 ssis packages one by one to read 20 textfiles on a share. One of the packages (always the "same" filename) fails sporadically: one or more successfull reads, then one or more failed reads, then one or more successful reads and so on.
This behavior used to happen for file A.csv but not anymore and the file B.csv is the current victim. When the job fails I run succsessfully all the unfinished packages manually using the same domain account as the service uses.
"
Error during execution of package ...
Connection B failed validation.
The file name \share\folder\B.csv specified in the connection was not valid.
The file name property is not valid. The file name is a device or contains invalid characters.
"
Internet search provides comments like privileges ons the share, folders on the path and the file it self. But I think that is not the problem because the domain account does have these privileges and the reads (through the service) are sometimes succsessfull.
Any help will be well received
regards Bernódus
Try using path for shared folder with IP for example \\10.150.0.1\sharedFolder\B.csv
or without IP as \\server\sharedFolder\B.csv
If it's fail-pass then check whether that file is used by any other process\user, since it's on share so there are chances.
One of the workarounds is to have the network path mapped to a drive on the host server of the package.
You have make UNC paths to work on the calling machine, the server or the destination machine.
It could be a permissions issue.
Check permission on shared folder for -
Your personal Windows login account
Windows account which is owner of the SSIS Service
We use to have a sporadic copy file to shared drive failure. Everything would be executing fine for about a few weeks or a month or so and then failed task with error on "Network path" or "login failure".
We found that the job was taking too long with one of the tasks and some how it was giving errors.
We had to modify the packages to improve performance to fix the problem.
Check your SQL Agent Job history to see if the tasks were taking a long time when the failure occurred.
Is there anyway to improve on the package performance or separate the package into multiple packages to run in SQL Agent one package after another
Hope the information helps.
I am working on an application which bulk-loads data into a SQL Server 2008 database. It writes a CSV file to a network share then calls a stored procedure which contains a BULK INSERT command.
I'm migrating the application to what amounts to a completely new network. In this new world bulk insertion fails with this error:
Msg 4861, Level 16, State 1, Line 1
Cannot bulk load because the file "\\myserver\share\subfolder\filename" could not be opened. Operating system error code 5(failed to retrieve text for this error. Reason: 15105).
I connect to the database using Windows Authentication, using the same account which wrote the file. The file, and the folder in which it resides, grant read and modify rights both to my user account and the database server's domain service account. That service account apparently has constrained delegation permitted, which is mentioned on MSDN. Still no good. If I connect using a SQL Server account then bulk insertion succeeds, but we are trying to stick exclusively to Windows Authentication.
Does anybody have a handle on what needs to be done to make this work? How exactly does SQL Server go about accessing data on network shares, hopping between its service account and that of the connected user? I know that I can bulk insert in a similar situation in our current infrastructure, but it is so crufty with age that it would be hard to track down what has been done to enable this in the past.
Recently we had this issue for a number of our Devs. I've come up with a number of ways to allow testing of bulk inserts.
Our preference was to use a SQL service account. We set the SQL server and SQL agent to run as a service account and then allowed the devs to trigger agent jobs. The service account was granted permission to the UNC shares and this all functioned correctly. Note that the service account will always been fine running these agent jobs (assuming UNC permissions are set). It's the Devs trying to test that will come across these issues.
Another method is to create a share on the SQL server itself and point the bulk insert path at the local directory. These errors seem to only occur when accessing UNC paths. Regardless of whether the UNC path has the correct permissions to allow you access. For example we create C:\test\ as a folder on the SQL server itself and permission it to allow a dev to drop test files there. These are then called via the bulk insert command.
A command may need to be run against master to allow a SQL login group permission to bulk insert. This is as below.
GRANT ADMINISTER BULK OPERATIONS TO "domain\usergroup"
Adam Saxton's blog (about Kerberos and bulk inserts from a share) should be read: http://blogs.msdn.com/b/psssql/archive/2012/09/07/bulk-insert-and-kerberos.aspx. Adam offers two approaches:
Enable constrained delegation for the machine (as opposed to the sqlservr.exe startup) account, or use a SQL Server login. Adam mentions two other approaches (which he does not recommend).
An aside, the latter half of the OP's message "(failed to retrieve text for this error. Reason: 15105)" may be related to a SQL Server startup account lacking rights documented within SQL Server's "Configure Windows Service Accounts and Permissions" topic, such as SeAssignPrimaryTokenPrivilege.
Did you ever resolve this issue? I recently had a similar problem and discovered that the best way to resolve it was to use a SQL login.
Initially, having read the notes here I thought if I just granted read permissions to the Windows account with which I was connecting to the SQL Server that would be okay, but even when I granted read access to Everyone, I still couldn't read in the file.
I believe the reason is something to do with SQL Server impersonating the windows user and attempting to access the UNC share, which is delegation and which is not allowed unless explicitly enabled. There are some notes here which may help. This is the constrained delegation of which you speak and I couldn't get it to work either!
Bottom Line: I just used a SQL Login and made sure the SQL Server Process account had read permissions on the share (by granting read to Everyone in my case) and it worked.
In order to bulk insert with AD users, the SQL service it self has to be running as a domain user and has to have the AD permission to be able to delegate authentication. Same if you wanted to run linked servers with ad users. Here is the link for AD and linked servers, but the permission are the same.
Linked Servers and Active Directory
The server must have an SPN registered by the domain administrator.
The account under which SQL Server is running must be trusted for delegation.
The server must be using TCP/IP or named pipes network connectivity.
When trying to restore my backuped TFSCollection via Administration Console (attach collection) the attachment fails. (NullReference Exception)
Are there any problems when restoring collections without the original configuration database?
The Collections is listed, but state doesn`t change from "offline", even when i tried to re-run the job.
When looking into [TFSCollection].[tbl_projects] via Management Studio I can see all projects.
When trying to restore the collection via
TFSConfig RegisterDB /sqlInstance:DataCenter\MSSQLServer /databaseName:DataCenter\MSSQLServer;Tfs_Configuration
I get the following error:
The following exception was caught while trying to validate the database: Keyword not supported: 'tfs_configuration;integrated security'.
Or when i run:
TFSConfig recover /ConfigurationDB:DataCenter\MSSQLServer;Tfs_Configuration /CollectionDB:DataCenter\MSSQLServer;Tfs_TFSCollection
The following error occurs:
TF246017: Team Foundation Server could not connect to the database. Verify that
the server that is hosting the database is operational, and that network problem
s are not blocking communication with the server.
Maybe I´ve run into some serious problem when installing TFS Service Pack 1.
What could i do to restore my TFS?
Even the import in my virtual enviroment fails. See the logfile.
If anyone had the same problem, take a look at http://support.microsoft.com/kb/2516423.
If you cant access your collections you could try.
TfsConfig updates /reapply
To start the TFS Job Agent you can run.
TfsServiceControl unquiesce
Or if the "Serviving" State doesnt change you could try this.
TfsConfig diagnose /scope:updates
TfsConfig updates /reapply
Hope this could help..
Below is the query that I am using to backup (create a .bak) my database.
However, whenever I run it, I always get this error message:
Msg 3201, Level 16, State 1, Line 1
Cannot open backup device 'C:\Users\Me\Desktop\Backup\MyDB.Bak'. Operating system error 5(Access is denied.).
Msg 3013, Level 16, State 1, Line 1
BACKUP DATABASE is terminating abnormally.
This is my query:
BACKUP DATABASE AcinsoftDB
TO DISK = 'C:\Users\Me\Desktop\Backup\MyDB.Bak'
WITH FORMAT,
MEDIANAME = 'C_SQLServerBackups',
NAME = 'Full Backup of MyDB';
Yeah I just scored this one.
Look in Windows Services. Start > Administration > Services
Find the Service in the list called: SQL Server (MSSQLSERVER) look for the "Log On As" column (need to add it if it doesn't exist in the list).
This is the account you need to give permissions to the directory, right click in explorer > properties > Shares (And Security)
NOTE: Remember to give permissions to the actual directory AND to the share if you are going across the network.
Apply and wait for the permissions to propogate, try the backup again.
NOTE 2: if you are backing up across the network and your SQL is running as "Local Service" then you are in trouble ... you can try assigning permissions or it may be easier to backup locally and xcopy across outside of SQL Server (an hour later).
NOTE 3: If you're running as network service then SOMETIMES the remote machine will not recognize the network serivce on your SQL Server. If this is the case you need to add permissions for the actual computer itself eg. MyServer$.
Go to the SQL server folder in start menu and click configuration tools
Select SQL Server configuration manager
On SQL server services, on the desired instance change the (Log On as) to local system
In order to find out which user you need to give permission to do the restore process, you can follow the following steps:
You need to go to your server where SQL Server is installed. Find SQL Server Configuration Manager
Next, you need to go to "SQL Server Services"
Under your SQL Server (MSSQLSERVER) instance there will be an account with column "Logon As", in my case it is NT Service\MSSQLSERVER.
That is the account which you need to add under Security tab of your source .bak location and give that user the "Read" permissions so that the backup file can be read.
Let's say your backup file is present at "D:\Shared" folder, then you need to give permissions like this:
One of the reason why this happens is you are running your MSSQLSERVER Service not using a local system. To fix this issue, use the following steps.
Open run using Windows + R
Type services.msc and a services dialog will open
Find SQL Server (MSSQLSERVER)
Right click and click on properties.
Go to Log on tab
Select Local System account and click on "Apply" and "OK"
Click on Stop link on the left panel by selecting the "SQL Server (MSSQLSERVER)" and Start it again once completely stopped.
Enjoy your backup.
Hope it helps you well, as it did to me. Cheers!
The SQL Server service account does not have permissions to write to the folder C:\Users\Kimpoy\Desktop\Backup\
I had this issue recently as well, however I was running the backup job from server A but the database being backed up was on server B to a file share on server C. When the agent on server A tells server B to run a backup t-sql command, its actually the service account that sql is running under on SERVER B that attempts to write the backup to server C.
Just remember, its the service account of the sql server performing the actual BACKUP DATABASE command is what needs privileges on the file system, not the agent.
I face the same problem with SQL Express 2014 SP1 on Windows 10.
Solution which work
Open Service by typing Services
Locate and open the SQL Server (SQLExpress)
Go to the LogOn Tab
Choose Local System Account ( Also Check for Allow Services to interact with desktop )
Click OK . Stop the service . Restart the service.
Problem solved
I was just going through this myself. I had ensured that my MSSQLSERVER login user had full access but it was still causing issues. It only worked once I moved the destination to the root of C. More importantly out of a user folder (even though I had a share with full permissions - even tried "Everyone" as a test).
I don't know if i consider my issue "fixed", however it is "working".
Just a FYI for any other users that come across this thread.
I had a similar issue. I added write permissions to the .bak file itself, and my folder that I was writing the backup to for the NETWORK SERVICE user. To add permissions just right-click what file/directory you want to alter, select the security tab, and add the appropriate users/permissions there.
Here is what I did to by-pass the issue.
1) Go to backup
2) Remove the destination file-path to disk
3) Click on Add
4) In the File name: check box manually type in the backup name after ..\backup like below where Yourdb.bak is the database backup name
C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Backup\Yourdb.bak
5) Click on OK
Hope this helps!
I solved the same problem with the following 3 steps:
I store my backup file in other folder path that's worked right.
View different of security tab two folders (as below image).
Edit permission in security tab folder that's not worked right.
I know it is not an exact solution but using external drive paths solves this problem.
BACKUP DATABASE AcinsoftDB
TO DISK = 'E:\MyDB.Bak'
WITH FORMAT,
MEDIANAME = 'C_SQLServerBackups',
NAME = 'Full Backup of MyDB';
I have the same error. Following changes helped me to fix this.
I had to check Server Manager->Tool->Services and find the user ("Log
On As" column) for service: SQL Server (SQLEXPRESS).
I went to the local folder (C:\Users\Me\Desktop\Backup) and added "NT
Service\MSSQL$SQLEXPRESS" as the user to give Write permissions.
SQL Server is not able to access (write) the backup into the location specified.
First you need to verify the service account on which the Sql server is running. This can be done by using Configuration manager or Services.msc.
or
Use below query :
SELECT DSS.servicename,
DSS.startup_type_desc,
DSS.status_desc,
DSS.last_startup_time,
DSS.service_account,
DSS.is_clustered,
DSS.cluster_nodename,
DSS.filename,
DSS.startup_type,
DSS.status,
DSS.process_id FROM sys.dm_server_services AS DSS;
Now look at the column service_account and note it down.
Go to the location where you are trying to take the backup.In your case : C:\Users\Me\Desktop\Backup
Right click--> Properties --> Security -->
Add the service account and provide read/write permissions. This will resolve the issue.
In my case, I forgot to name the backup file and it kept giving me the same permission error :/
TO DISK N'{path}\WRITE_YOUR_BACKUP_FILENAME_HERE.bak'
I had the same issue and the url below really helped me.
It might help you as well.
http://blog.sqlauthority.com/2011/04/13/sql-server-fix-error-msg-3201-level-16-cannot-open-backup-device-operating-system-error-5access-is-denied/
Msg 3201, Level 16, State 1, Line 1
Cannot open backup device 'C:\Backup\Adventure_20120720_1024AM.trn'. Operating system error 5(Access is denied.).
Msg 3013, Level 16, State 1, Line 1
BACKUP LOG is terminating abnormally.
I verified backup folder on C drive, Is new service account is having full control access permission or not?, I realized that "Test\Kiran" service account is not having Full control security permission.
Please follow the below steps to give full control to service account:
Go to C drive, Right click on Backup folder.
Select Security tab.
Click on Edit button, new window will open.
Click on Add button and enter Test\Kiran user account and click check name button, this will validate you entered user is existing or not, if it is existing it will show the user on window, select OK.
Select you entered user name and select Full Control check box under allow.
Please check the access to drives.First create one folder and go to folder properties ,
You may find the security tab ,click on that check whether your user id having the access or not.
if couldn't find the your id,please click the add buttion and give user name with full access.
Share this folder and use UNC path, by example: \pc\backups\mydb.bak
Then You can stop share.
Not very elegant, but it resolves all permissions problems (You need to give permissions to share as well, as mentioned above)
I experienced this problem when the .BAK file was temporarily stored in a folder encrypted with BitLocker. It retained the encryption after it was moved to a different folder.
The NETWORK SERVICE account was unable to decrypt the file and gave this thoroughly informative error message.
Removing BitLocker encryption (by unchecking "Encrypt contents to secure data" in the file properties) on the .BAK file resolved the issue.
Hi you need to change the query from:
BACKUP DATABASE AcinsoftDB
TO DISK = 'C:\Users\Me\Desktop\Backup\MyDB.Bak'
to
BACKUP DATABASE AcinsoftDB
TO DISK = N'C:\Users\Me\Desktop\Backup\MyDB.Bak'
You have to add a N in front of the path works for me.
My issue was that the "File Ownership" was set to my company. I changed it to "Personal" and it worked. Right click the file and click the "File Ownership >" option and then change it to "Personal". I believe this happens with all files sent over Microsoft Teams.
If the backup destination path resides on your local machine, change the account of 'SQL Server' service to 'Local System Account', then everything must be resolved, keep in mind that the 'SQL Server' instance service is responsible to access the backup destination so the account it is running under, must have access to the destination path of your backup.
Make sure you are actually saving to a FILE and not a folder,
My problem was I was simply putting in the Folder path and not the File path
You want this
'F:\Database Backup\Pharmacy\data.bak';
You dont want this
'F:\Database Backup\Pharmacy';