I'm attempting to get SQL Server Service Broker working across database instances and an at the stage of copying certificates (from initiator to target and vice versa). I can back up the certificate to a file but once created I can't open the file or copy it to any other location. If I try and open the file I get a message box with the title "Invalid Public Key Security Object File" and the message "Access is denied.".
The server is within the local domain and is running Windows Server 2008 R2 Enterprise with SP1.
This works (but I cannot do anything with the file):
BACKUP CERTIFICATE UserCertificateB TO FILE='C:\Certs\UserCertificateB.cer';
This doesn't work:
BACKUP CERTIFICATE UserCertificateB TO FILE='\\localmachine\Certs\UserCertificateB.cer';
Error message is:
Msg 15240, Level 16, State 1, Line 2
Cannot write into file '\localmachine\Certs\UserCertificateB.cer'. Verify that you have write permissions, that the file path is valid, and that the file does not already exist.
I can back up the certificate to a file but once created I can't open the file or copy it to any other location.
Yes, the access is restricted to the SQL Server service account. Grant permissions as appropriate on the file, using an administrative account. Use icacls.
Cannot write into file '\localmachine\Certs...'
You are doing a 'double hop' so it requires Kerberos constrained delegation. Contact your network administrator to set it up properly for you.
I know this is an old question, but maybe this answer will be relevant to others that may find the same issue.
If it shows the error ‘Msg 15240, Level 16, State 1, Line 8
Cannot write into file 'C:\tmp\cert\MY_TDE_CERT_KEY.PVK'.
Verify that you have write permissions, that the file path is valid, and that the file does not already exist.’
It is because the script has to be executed on the server and not the local computer connected to the server.
Once the SQL script executed in the server then the files will appear in the selected folder in the server (must create a local directory).
Error (the image shows the path of the local computer, it was the wrong path, must be in the server):
After executing in server
Learned this from Microsoft:
"The path is relative to the SQL Server instance. The path needs to be setup on the machine hosting the instance."
Related
I have an SSIS package that is supposed to read a folder and if the folder contains any text files, it will read them and store the data into a database. The package works flawlessly from the file system, however when I deployed it it fails.
The package uses a project level variable that remains consistent that acts as a folder path to see which folder to look in for files.
The SQL Server Agent gives me this error:
After looking at the execution report I see following error messages if I execute it with the service account through SQL Server Agent:
"The file name property is not valid. The file name is a device or contains invalid characters"
"The file name '(path here)' specified in the connection was not valid"
"The Flat File Connection manager failed validation"
However, if I run it myself by directly right clicking on the package in the catalog and executing, the execution report will come back as successful but it will contain a warning that says: "Read Files From File Input Folder Warning: The For Each File enumerator is empty. The For Each File enumerator did not find any files that matched the file pattern, or the specified directory was empty"
I suspect it is a permissions error, but I haven't dealt much with the permissions in Microsoft SQL Server and the service account that I am using was not created by me. I have tried changing the security of both package and project from the default "Encrypt sensitive data with user key" to "Do not save sensitive data", rebuilding and redeploying but that didn't help at all.
It is most likely a permissions error but I've been puzzled on how to go about it. Any help is much appreciated!
EDIT: After setting the "Delay Validation" on tasks in the control flow and executing the package with SQL Server Agent it now comes back with 2 less errors
For filesystem task to work the executing account need permission to the folder in question. When you execute the package via the SQL-agent the package is executed under the account running the SQL-agent account, when you right click the package and press execute the package is executed as your account.
One problem could be that the SQL-agent account doesn't have permission to the folder, and can't enumerate the content. You can verify this by changing the SQL-server account to your own account temporary and running the job again:
Open Sql Server Configuraiton Manager
Under SQL Server Services double click SQL Server Aggent
Change the account to your own account
Restart the service
If this resolvs the problem, change back to the SQL-server account and check the folder permissions on the folder you are trying to enumerate. Add the SQL-agent account or group the account is included in to have permission to read the folder. Obviously you can also just check the folder permissions to begin with, and make sure the executing account have permission to it.
I am getting following error on BULK INSERT after the file location was changed to remote share. Before it used to be a shared folder in local drive and we never ran into this issue. I am running this BULK INSERT from my local PC connecting to SQL Server via SSMS.
I have made sure both SQL server and file permissions are in place.
Before when I ran this command from SSMS, it was \\SQLServer\FTP location which was a shared folder in local drive in that SQL Server but now I changed the file location to a network share \\Fileshare\FTP and have the above error but both SQL service account (domain account) and me (domain account) have elevated permission on that new location.
Any help or suggestions!!
Thanks,
I can identify three circumstances that might generate this issue:
From the SQLAuthority Blog, full detail on a related backup issue where there is a cross-domain link (in this case, from a workgroup to a full domain).
There are also two other possible answers in the question Cannot bulk load because the file could not be opened. Operating system error code 1326(Logon failure: unknown user name or bad password.) here on StackOverflow. We can discount the first one (login permissions) because you stated that you had permissions, but the other solution (I fixed it by adding the SQL Server port number to the connection string in SSIS, forcing SSIS to access SQL Server through TCP/IP instead of Named Pipes.) could apply. Try forcing a connection to the server using TCP/IP.
All of these issues appear to be related to having an attempt at cross-domain communication. If this is the issue with you, one or more of these fixes should be applicable to your issue.
-
It finally worked....
I had to configure Kerberos Authentication following the guide from this link https://thesqldude.com/2011/12/30/how-to-sql-server-bulk-insert-with-constrained-delegation-access-is-denied/.
Of course, I had to make adjustments to suit our environment and had to involve Active Directory Admin for creating SPNs and enabling DELEGATION properties.
Thanks.
I am running the following query in SQL Server 11.0.
BULK INSERT [dbo].[Andy] FROM "Y:\users\joe\APP data main file.csv"
WITH (FIRSTROW = 2, FIELDTERMINATOR = ',' ,
ROWTERMINATOR = '\n', TABLOCK)
The command is returning the error,
Cannot bulk load because the file "Y:\users\joe\APP data main
file.csv" could not be opened. Operating system error code 3(The
system cannot find the path specified.).
The cause of this error, from researching it online, is that the Bulk Insert task runs by executing the Bulk Insert command from the target SQL server to load the file. This means that the SQL Server Agent of the target SQL server should have permissions on the file I am trying to load. How can I find out whether it does or not?
Secondly, according to Microsoft’s website, “…if a SQL Server user logs on by using Windows Authentication, the user can read only those files that can be accessed by the user account, regardless of the security profile of the SQL Server process.”
I log onto SQL Server using Windows Authentication. By the definition on the MS website, I have access to the file I am trying to insert from. I created it, and I can open it. More specifically, the Windows account I’ve logged onto (my own) is the account that created the csv file, and is the account through which I open SQL Server. Yet the error is there. There is something I am missing, but I have no idea what it is.
Finally, it doesn’t matter whether or not I use the UNC path to access the file, or the drive mapping.
Looks like the file is located on network server, you are referencing mapped drive name, try use UNC network path instead.
I had an email back from my IT department on this question:
The problem I think is that you’re assigned to a server role based on
the user policy group that you’ve been assigned to - which would
correspond with a particular server role - by the network
administrators and this server role doesn’t have access to the file
path for whatever reason. You may have access to the server path
yourself because of another group to which you currently are assigned
but if that group doesn’t correspond with the server role, the server
role won’t have access.
So there we have it. It has since transpired that I can't bulk upload anyway for operational reasons, so I won't be pursuing this any further.
Thanks all for your help.
I am trying to import data from an Access 2003 mdb database using OpenDataSource with the ACE OLEDB driver. I'm getting this error:
Description: OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "(null)" returned message "Cannot start your application. The workgroup information file is missing or opened exclusively by another user.".
I have no idea what it's talking about, and my internet searches have not helped. They all refer to linked servers, and anything I've tried has done nothing to fix the problem. What does this error mean, and what do I need to do to fix it?
The sproc which does the importing is called from an SSIS package, which goes through a table of file locations and calls the sproc for each of them. I just discovered that the package ran for about half an hour, getting about 80 files imported, before it began throwing this error. I have as yet been unable to find any difference between the files that worked and the ones that didn't.
From Understanding the role of workgroup information files in Access security:
The workgroup information file is a required component when you use a
Microsoft Access database (MDB). This file is required for both a
run-time installation and a full installation of Microsoft Access.
This file is an important component of Microsoft Access security.
If you develop database applications, it is important that you have a
good understanding of the workgroup information file. It is a good
idea to reserve the last phase of the development process for applying
security in Access. Until then, you can develop the database
application in an unsecured database.
A workgroup is a group of users who share data in a multiuser
environment. When security is implemented on a database, the user and
group accounts are recorded in the workgroup information file. User
passwords are also stored in the workgroup information file.
IMPORTANT: If you establish Access security in a database, Microsoft
recommends that you store a backup copy of the workgroup information
file in a safe location. If the file is lost or damaged, the only way
to recover the workgroup information file quickly is to restore the
file from a backup copy. If you do not have a backup copy, you must
re-create the User and Group Accounts with the same Personal IDs that
were originally assigned. If the new workgroup information file is not
created exactly as the original file, you will not be able to open the
database with the workgroup file.
Access uses the workgroup information file even when the database has
not been secured. The default Admin user account, which is stored in
the workgroup information file, is used to open all unsecured
databases. If you assign a password to the Admin user, you will
receive a logon prompt when you reopen the database.
The Access database that SQL Server is trying to access is being used by another user. Go to the folder where the database is stored. With Access 2003, the database file itself will end in 'mdb'. If there is a file with the same name but ending in 'idb', it signals that there is a user currently using the 'mdb' file. Have the user exit the database and then run your package. If you can't find the user using the file, make a copy of the file in another folder and edit your SSIS package to reflect the change.
I'm transitioning email services in an web (mvc3) application from .Net to sql Database Mail. Some of the content we want to send as attachments has been uploaded to a sql FileTable. When I use the UNC path for the attachment (#file_attachments=), I get this error:
Msg 22051, Level 16, State 1, Line 0 Attachment file
\\computername\mssqlserver\foldername\foldername\DE107D2C-B945-4F1E-A4B9-4B398C9DE758.jpg)
is invalid.
I can open the file directly using the same path, and when I copy the file to a local folder, the file attaches fine. I suspect that the issue is folder permission for the FileTable directory. But I can't find any hooks to set the rights for that folder.
I'm running the EXECUTE msdb.dbo.sp_send_dbmail locally in SSMS (local sql instance) using windows authentication.
Any suggestions would be much appreciated.
This behavior was validated in the Microsoft Database Engine forum and I submitted feedback: https://connect.microsoft.com/SQLServer/feedback/details/756716/sql-server-database-mail-attachments-from-filetable-msg-22051-file-is-invalid
Note that the error code I had in this title should be 22051 and not 22015.
In the mean time, I'm using a work around of copying the files using the sql command shell to another local folder, and using that path for the attachment
Thanks.
share your attachement folder to Network service user in which attchment file exist.
and give attachemnt file path like \\ip_addres\filefolder\abc.pdf to send_dbmail stored procedure.
This will work if file and sql server are on different machines