Applies to: AFT!
Version(s): All

In the Windows operating system, by design, UNC paths (shared folders) cannot be accessed by the LocalSystem virtual user profile; this means that system services typically cannot access shared folders. Oftentimes the suggested workaround would be to run the system service impersonating a different user profile, a so-called service user, but that would be specific only to the Windows operating system, while AFT! is a cross-platform software.

So, the best workaround to keep the software cross-platform and at the same time address this limitation in the Windows operating system painlessly is to mount the shared path as a drive (with its own drive letter) in the context of the LocalSystem virtual user profile.

Although mounting a shared folder as a virtual drive is typically a trivial task, it's not that intuitive to mount it in the context of the LocalSystem virtual user profile. In fact, the most effective way to do so is via the command-line.

Open a Command Prompt "as Administrator", and type in the following command (after customizing it to suit your needs):

schtasks /create /tn "my_share" /tr "net use Z: \\hostname\directory /persistent:yes" /sc onstart /RU SYSTEM /RL HIGHEST

Of course, you will have to use your own actual information in such command. Here's what you will typically have to change in it to make it work for you:

  • "my_share" - use any suitable task name, better if it doesn't contain any spaces or special characters
  • Z: - remember to use a different drive letter for each shared folder you mount for LocalSystem
  • \\hostname\directory - this will obviously have to be the full UNC path to the shared folder you want to mount

So, what does this command do, exactly?

It creates a persistent, high-priority task in your Windows scheduler service that mounts the desired shared folder as a pre-determined drive letter every time your operating system starts (or reboots).

The beauty and the elegance of this method is that not only it's a "set and forget" type of task, but also that it allows to access shared locations in your scripts as if they were local drives, so your scripts will be consistent regardless of where the data actually resides.

Not only! Being a Windows scheduler task it's easy to remove if or when you don't need it anymore.