Access Not Authorized Error

[Scott.Macmaster]

We recently upgraded our job server to Windows Server 2008. We have jobs we run manually in a folder (c:\Custom Programs\). Some programs are console programs others are have a gui. This one program has a gui. It also has a progress bar that shows the progress of the job when you click the go button. Of course it spawns a thread to do the processing. This thread creates a log file to write errors and other things too.

The problem is when the program goes to create the log file an access not authorized error is thrown. I checked the permission on the folder. All users are allowed to create/edit/append/execute. Pretty much everything except take ownership. Also, there's nothing that denies anything. So I see no reason why this isn't working.

We can get this to work by using the run as administrator option when we first run the program. However, we don't view this as unacceptable solution. My only thought is the spawned thread isn't getting the same permission set as the program. Am I correct or does something think it's something else.

This is the code I use to spawn the thread.

       Dim newThread As New Thread(AddressOf obj.DoProcessing)

        newThread.Start()

Can someone help?

Thanks,
Scott

[dglienna]

What file is being written to? What folder? Windows 2008 is the same as Windows 7 (which has a \ProgramData folder that's hidden)

Your app should ONLY write to a subfolder of THAT. That way permissions are different than where the program exe resides

[Scott.Macmaster]

It writes to the same folder it was executed from. In this case, c:\Custom Programs. I've never used /ProgramData before. Am I supposed to create a subfolder in it that has the same name as the program and then write data in it.

Hmm, I really don't want to do that. I want to keep everything in one place so our operators don't have to go hunting all over the place for output files.

Another thing I don't understand is why it works fine when I run the program from, C:\Software\Inhouse\Projects\ProcessData\ProcessData\bin\Debug but not from C:\Custom Programs. We use the same server for development.

Any other ideas?


Thanks,
Scott

[dglienna]

Try a sub-folder. That *could* cause problems in a root folder, I think

[Scott.Macmaster]

I changed it to write to C:\Custom Programs\Logs. It worked when I ran it. However, when someone else tries to use it it doesn't work. I suspect that it has something to my being an owner of the newly create folder/file. It seems really wierd to me that we have to do 'run as administrator' when we'll all members of the domain administrators group to simple write to a file.

Do you have any more suggestions?


Thanks,
Scott

[dglienna]

Well, you could make THAT folder PUBLIC (or Guest) or whatever works.
Otherwise, you'd have to learn how to IMPERSONATE the Administrator account.

It can be done, but I don't want to post it for the whole world...

[Scott.Macmaster]

It would be nice if impersonating was as easy as it is in ASP.NET. However, I'd rather not require that the program be run as administrator or even have to program automatically impersonate administrator.

I'd like to try this public folder idea. I'm not sure how to do that. I tried turning on sharing thinking that might be it but it didn't work (I did go into permissions and made sure both read and write were checked).

Any more suggestions?


Thanks,
Scott

[dglienna]

Share the folder, and give EVERYONE access to CHANGE the files. Then, it's public

As far as programdata, that's what you're SUPPOSED to do now. Create a duplicate foldername as you use in Program Files

[Scott.Macmaster]

I think we're looking in the wrong area. I talked with our network admin this morning. His first thought was it has something to do with DEP.

We tried adding the program to the list of allowed program. However, I got this error message, "This program must be run with data execution protection (DEP) enabled. You cannot turn off DEP for this program."

Is there some compiler settings or something else that I can change so the program will be compiled in a way to will allow me to add the program to the list of allowed programs.

Also, we went to the 'compatibility settings for all users' for one of my programs and set it to run in Windows XP SP2 compatibility mode. This allowed it to create the output files without having to do run as administrator. This definitely is better because users don't have to select run as administrator. Plus, they can access their network drive in the open dialog. When they do run as administrator the open dialog in the program doesn't show the users network drive.

The only problem with this is I'd have to remember to change that setting whenever I recompile the program and copy it to the custom program folder. So I would really like to find out how to get it to compile in a way to will allow it to write files.

Do you have any suggestions?


Thanks,
Scott

[dglienna]

Same as before. Have you tried \ProgramData?

My friend fought with an old Windows program that produces a log file. Solved the same way. I have a VB6 app that I install on the server. It writes files. Same way. (Not as a separate thread though)

[Scott.Macmaster]

Creating a folder under /ProgramData that has the same name as the executable and creating the output files there does work. However, we want to keep everything in the same location. So this isn't an acceptable solution. We have about 20 different jobs. We can't have our operators hunting around for files in a bunch of different folder that's under an entirely different folder.

I discovered that the setting to run in WindowxXP SP2 compatibility mode somehow stays set even after replacing the executable with a newly compiled. So I think I'm going go with that solution. However, I don't know if there's any downside to using the compability mode. Do you know of any?


Thanks,
Scott

[dglienna]

Not anything that is a deal breaker, but not the recommended option. How hard is it to MAP a drive letter to the sub-folder that has the data? Drive J: could be used, for instance