By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,534 Members | 943 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,534 IT Pros & Developers. It's quick & easy.

Permission Denied to my application when copying file to share...

P: 296
My application uses the following code to run a batch file.
Expand|Select|Wrap|Line Numbers
  1.         Dim DOSProc As New Process
  2.         With DOSProc
  3.             .StartInfo.UseShellExecute = False
  4.             .StartInfo.FileName = "c:\scripts\copyimages.bat"
  5.             .StartInfo.Arguments = Chr(34) & PPSParam.LatestImageFile & Chr(34) & " " &
  6.                                    Chr(34) & PPSParam.Panelname & Chr(34) & " " &
  7.                                    Chr(34) & PPSParam.Comment & Chr(34)
  9.             .StartInfo.ErrorDialog = False
  10.             .StartInfo.WorkingDirectory = "c:\scripts"
  11.             .StartInfo.CreateNoWindow = True
  12.             .Start()
  13.         End With
The code above was simplified for readability.
It essentially opens a command window and the batch file runs. In this case the batch file is simply copying a file from a location on the local machine to a writable share on the network. I have checked the share and security is set so that Everyone has full access (read/write/delete/etc - all the boxes are checked). If I open a cmd window and run the batch file it works perfectly. But when the above code runs the batch file the copy function gets "Permission Denied"
Any clues what I am doing wrong here?
Could it have anything to do with useshellexecute?
Nov 19 '13 #1
Share this Question
Share on Google+
1 Reply

P: 296
The problem turned out to be the fact that my program was started by a service running as system. When that happened my program inherited the system user and shares are not available to system users.
I had to change the way the service called my application (it was a service I wrote) so that it would impersonate the "primary console" user (aka the desktop) in Windows.
In order to use this it required several Win32 APIs. At some point I may submit an article here on how this is done - I wound up writing a DLL, but for now suffice to say that processes started by services will have problems with permissions and security until you run the process impersonating the user logged onto the primary console.
Dec 21 '13 #2

Post your reply

Sign in to post your reply or Sign up for a free account.