We have created a windows service (.NET app - lets call it CHS) that moves files on schedules (with full auditing, unzipping, renaming, etc.)
I updated the CB service to use the same domain account that is used by the CHS app which has full RW access to file shares on the server as well as the network.
Using the drive letter in a job configuration, gets us access denied (like drive isn't even there)
Using the UNC path for the network mapped drive (yes allow access has been checked as well), same error. ('Access to the path '\\server02\rma_root\somerawdata\FRC\test-1a.txt' is denied')
Any suggestions on how to get the drive to remain available?
I'm not sure what you're trying to do is supported. Drive is exposing the cloud as a network share and you're trying to access that share from another service. Unlike a user account that is accessing the share when logged in, I do not know if services have that same level of access. What you might try doing is ensuring the Drive service starts up immediately on Windows boot and setting the other service on a delay to ensure Drive is fully started first. I don't know if the custom service is trying to access the share before it's ready to be shared.
Again, though, I think this might be better sent to Support for best resolution. Even if it's not currently supported or working properly, they can raise the requirement to try to have it addressed in a future release after an analysis of the logs.
David,
The Service manages scheduled jobs (within it's UI application) to move/copy files. That service only accesses the CB Drive when a specific scheduled job tries to copy files there.
In the UI for the Service, we can define a pre-PowerShell script before a transfer definition runs. (which copies files from Source to Destination). I've added the following as a pre-script: $Command = "C:\Program Files\CloudBerryLab\CloudBerry Drive\cbd.exe"
$Parms = "mountDrive R"
$Prms = $Parms.Split(" ")
& "$Command" $Prms
Then as a post script I unmount the drive.. this seems to be working.
Are you saying that if you run that script, everything works fine that was your workaround for the issue? Or are you saying that the script works, but you still have access issues?
My concern would be that if you are not starting Drive until the transfer is needed, it can take some time to mount and get ready. So putting in a delay between the pre-script and any access to the files in the share might help.
The Drive service is always running.. the defined drives are not mounted. So the script mounts the drive copies the files, then unmounts...
Also, the service will not try and copy files until the script finishes mounting the drive.