Hi,

Since you did not provide some additional details based on the behavior  described, there has to be a question of where this occurs. If the operation works correctly in desktop studio, but fails on Central (either internal worker or RAS) then the problem might come from the fact that while studio is run under the windows user as an application, by default Central and RAS are run under a local system account  and with these local system accounts even on a user/password authentication scheme there have been instances where based on share permissions the local system account was denied access. In such a case running the service as a domain account from a user that has permissions to the share might solve the problem.

In some cases UAC (user acces control) from windows has been known to interfere with accessing network shares and certain locations on local disk. Lowering the UAC level might also solve this issue if that is the problem.

Hope this helps,

Vlad

HI,

I start from the bottom: the UAC settings are already at a minimum.

The RAS service, it runs as domain\myuser:

• if domain\myuser has permissions to the share, access is allowed
• if domain\myuserr hasn't permissions to the share access is not allowed.

But if I have not misunderstood the primitive FSGetChildren requires the username used to access the file system among the input parameters

Input Parameters:
source - The directory to check.
delimiter - A delimiter to put between files and folders in the directory.
user - Username to use for thread impersonation on the RAS host when reading.
password - Password for the user.

I think that the solution of giving access to all shares to the user running the RAS service is not the best way to manage the security of infrastructure.

Thx, Alberto