It seems that there are two potential sources of the problem: 1. issues related to starting a new process and access to this UNC resource 2. problems related to permissions, regardless of whether the new process is used to access the UNC shared folder
I would start by testing # 2, checking if your site can read the file from a remote resource without starting a new process for this. For instance:
<% dim filesys, filetxt Const ForReading = 1, ForWriting = 2, ForAppending = 8 Set filesys = CreateObject("Scripting.FileSystemObject") Set filetxt = filesys.OpenTextFile("\\webdev2\SVC\streams\dev_f_fusion3\testfile.txt", ForReading, True) Response.Write (filetxt.ReadAll()) filetxt.Close %>
If this fails, your problem is probably relatively simple: your site does not have access to the remote resource. To fix, the easiest way would be to use anonymous authentication and select an anonymous user with access to the shared folder. Here's a tutorial explaining how to do this. Be sure to disable the built-in auth windows, as the tutorial recommends!
Also, make sure that you are very careful about how you process and avoid user input that translates to your EXE path, since you really do not want an attacker to be able to run arbitrary code on your network! Ideally, you would never create any part of the executable path or command line arguments directly based on user input, but only indirectly (for example, using user input to search for a known safe name in the database, and then use this database result in your path) .
There are other ways (besides anonymous auth as a domain user) to enable remote access, including delegation, using basic auth over HTTPS, etc. Let me know in more detail if you cannot use anonymous auth, and I can help you find the right alternative.
However, if the test with file access above is successful, your problem is more complicated - this means that the code running inside the IIS process has the correct access, but the spawned process does not inherit the ability to access remote resources.
UPDATE: according to your comment, you found that the problem is that the running process is starting under the wrong user account. This can be fixed by calling some Win32 APIs directly, and there are also .NET solutions, but if you don’t like external VBScript, it may be more than you want to accept right now.
Can you copy the file from the remote computer to a temporary file on the local computer, then run FFMPEG.EXE, and then (if you need to) save the changes to the remote server and finally delete the temporary file?
If you can do this, this will avoid the problem described in this thread, make it easier to find other problems (for example, a network failure) inside your ASP code, rather than hiding inside FFMPEG.EXE, and this may even improve performance depending on how efficiently FFMPEG.EXE handles remote file access.
Here is the code to copy the remote file to a temporary local location. A warning, perhaps some typos below, when I glued several samples to create it, and did not have time to test it myself.
<% dim filesys, filetxt Const ForReading = 1, ForWriting = 2, ForAppending = 8 Set filesys = CreateObject("Scripting.FileSystemObject") Const TemporaryFolder = 2 Dim tfolder, tname, tfile Set tfolder = fso.GetSpecialFolder(TemporaryFolder) tname = tFolder & "/" & fso.GetTempName Dim remoteFilename remoteFilename = "\\webdev2\SVC\streams\dev_f_fusion3\testfile.txt" Const OverwriteExisting = True filesys.CopyFile remoteFilename, tName, OverwriteExisting %>
I believe that this approach with local copying will give you better reliability and probably better performance, since copying all files over a network connection is usually faster than reading one fragment at a time. Also, your error handling and debugging will be easier if the operations most similar to failure (access to a network file) occur inside your code, and not because of strangers.
But if you are convinced that you need to call your EXE with UNC access, the best option is to create a COM component using C ++, C # or VB, which replaces Wsh.Shell as the start of your process. I would recommend creating a component using .NET instead of native C ++, because calls will be much easier. If you do this in .NET, you will want to use the System.Diagnostics.Process class to start your process using ProcessStartInfo to specify the username / password to use.
You can also try creating a connection using WNetAddConnection2 , and then start your process using CreateProcess or a similar Win32 API (or its .NET equivalent), but you may have to play around to find the options you need to use.
In other words, it is a difficult task to create this wrapper. Your best bet is probably your current decision.