5

I have a File System Task to copy a local file to a remote drive, using the UNC path. Recently the target file server was moved, so I updated the path, but now I'm getting this error message:

 [File System Task] Error: File or directory "\\path\filename.ext" represented by connection "XYZ" does not exist.

The file most definitely does exist; what else might cause this error?

I can copy the exact path into a Run dialog and open the file without any problem. I can also browse the target folder, and can write to or delete the file outside of VS. I do not have any rights on the parent folder, if that might be relevant.

The File Connection is set to Existing file. The File System Task is set to overwrite. The path is hard-coded, not an expression or variable. This report has been running for months, all that's changed now is the file server and path. The old path had also been UNC.

Most of what I've found online relates to deployment, but I'm developing on the server which runs the package (I know, it's not ideal), under the same account as that under which the package runs. In any case I get the same error when running via SQL Agent or debugging within VS.

Most maddening of all, other SSIS jobs write to the same folder without any trouble. However, those include a subsequent Execute Script task which renames the posted file, so the exact target file does not exist when they run. This package just overwrites the same file every day. If I can't fix this issue I'll add such a task here too.

If I delete the target file, the task will run... once. The next day the package will fail, as the target will again be present, and it seems the problem lies in overwriting an existing file. Of course I could insert a "delete" File System Task... except it also claims that the target does not exist.

I've tried re-creating the File Connection and File System Task, no change.

Screen cap of the File System Task

  • You may have permission problems. Make sure that the process has access to the file and the directory. – Ciarán Jul 05 '13 at 15:37
  • Yep. As mentioned, I can browse the directly and edit or delete the file. –  Jul 05 '13 at 16:00
  • Any chance the path is broken? Instead of `\\server\folder\filename.ext` it's something trivial like `\server\folder\filename.ext` that's bit me more than I care to admit. I would say though, that it sounds like you've been rather thorough in checking the obvious. I'd then go with a permission issue but you've stated you're using the same account to manually do these tasks. My guess of last resort would be some sort of quirk with the remote file system. Any chance it's a non-Windows machine? Otherwise, could you post a screen shot of the File System Task? – billinkc Jul 08 '13 at 01:54
  • @billinkc: I believe that's covered, I can copy the exact path and run it. There could be something squirrely about the new server, for sure. The powers that be discarded all privs and have re-created what I've specifically requested, on a limited basis. I'm reluctant to blame IT for this, though, since some packages **can** write to these folders. –  Jul 08 '13 at 14:13
  • Have you tried setting the Connection Manager's DelayValidation property to true? – adam Aug 05 '13 at 19:31
  • Also, while it seems this is not a DataFlow task, this url: http://microsoft-ssis.blogspot.nl/2012/09/swtich-package-from-64bit-to-32bit.html seems quite relevant due to your use of an xlsx file. – adam Aug 05 '13 at 19:33
  • @adam: A good idea, but it has no effect. Yes, I am using the 32-bit version; writing to Excel is working fine, it's copying the file that doesn't work when the destination already exists. –  Aug 05 '13 at 23:46

1 Answers1

6

I had the same problem long time ago and this solution worked for me.

My error was due to the use of a UNC path and the account runnnig the package not having access to ALL the folders and files in the path.

Internally SSIS package is trying to list all files and directories in \\path, if doing this a exception is throwed, you recive that error.

To solve this you need to ensure that the account running SSIS package has access to ALL folders and files in the path you are accessing.

To check if this works, logon as the relevant account, or run a command window as the specified user and then check you have full rights to all files and subdirectories.

Maybe you have the same issue. It worth a try.

jlvaquero
  • 8,571
  • 1
  • 29
  • 45
  • That fits - the kind of pointlessly error-prone thing that SSIS would do, and it fits with the fact that several directories in the path are locked out. Unfortunately I don't have another account with full rights to test it, but I'm sure you're correct. Thank you for illuminating this mystery! –  Aug 07 '13 at 15:02