Friday, July 24, 2009

Windows SYSTEM user

I have a program that copies files from one machine to another over a network. It uses port 445 (called the SMB port - SMB is a protocol for sharing files between computers in a network).

When I ran this program in MS DOS, the remote folder in which the remote files are in was recognised as a directory (i.e. dir.isDirectory() = true). However, when I ran this program from Windows Services, the remote folder was not recognised as a directory.

The reason for this was because of the user under which the program is ran. When it was run in MS DOS, the current Windows user (Administrator) was running the program. Hence, it had access priviledges to read/write the remote folder.

However, as the Windows Services process is controlled by System User, when the program was run in Windows Services, the program was run under the SYSTEM user, disallowing it to have access priviledges over the remote folder.

Basically, although a SYSTEM user is higher than an administrator and has full control of the OS and kernel, it cannot access remote systems. It is just for a local system.

To ensure that the program is run under the current Windows user (Administrator), you will need to set up the program's properties in services.msc. Click on the Properties of the program, then on the 'Log On' tab. Here, ensure that you log on as 'This Account' (type in your current Windows Administrator username and password) and NOT as 'Local System Account'.

This will allow the program (running as a Windows Service) to copy files over a network as it will be running under the current user. You can check the username it is running under by going to your Task Manager.

No comments:

Post a Comment

Thank you for your comment.