Introduction
Google Drive for Desktop Windows client (and once upon a time Google Backup & Sync) uses two temporary hidden folders, which are set in the local Google Drive folder root, to synchronize files and folders, online and locally. These are:
.tmp.drivedownload
.tmp.driveupload
When Google Drive for Desktop is synchronising files and folders, these are temporarily stored into the above folders.
For instance, let’s focus on the process occurring when a file is uploaded from a browser to Google Drive:
- Using a browser, the file notes.txt is uploaded to Google Drive into the folder
My Drive > Mike - Once the upload is completed, Google Drive for Desktop (or Backup and Sync), which is running on the client computer, will detect a change and will issue a download of the above file
- The file
notes.txtis downloaded into.tmp.drivedownloadon the local computer, then, assumingc:\driveis the Google Drive root folder, it is moved into the folderc:\drive\Mike
All this is perfectly reasonable, however, the issues arise as soon as the local computer which is running Google Drive for Desktop client is a Windows Server.
In this scenario, multiple users require accessing files in a secure way, as the system must ensure that file permissions are fully respected. In the following scheme, each user should only connect to its own folder.

Say that in the cloud, the Google Drive account “school@myschool.com” account is sharing some folders with users Mike, Sue, Bob. Each user can only access its own folders.
On the local Windows Server, which is running Google Drive for Desktop client, the folder structure replicates the online version, with NTFS ACLs set accordingly
In the above scenario, see what happens when user Mike uploads a file to Google Drive using a browser:
- The file
otherNotes.txtis uploaded to Google Drive into the folderMy Drive > Mike - Once the upload is completed, Google Drive for Desktop client (or Backup and Sync), which is running on the client computer, namely a Windows Server computer, will detect a change and will issue a download of the above file
- The file
otherNotes.txtis downloaded to the local computer into the folder.tmp.drivedownload, whose ACLs are inherited by the local user who installed the Google Drive for Desktop client (usually SYSTEM and Administrator accounts), therefore the downloaded file will inherit these permissions. - At this point, the above file is moved to the folder
c:\drive\mike, (which was originally set to grant exclusive access to user Mike), however, as the file is being moved across the same partition, it will retain the ACLs inherited in the previous step, preventing user Mike to access this file (see this article to better understand effects of ACLs when moving a file in the same partition or across multiple partitions)
A previously effective workaround (now broken!!)
As explained in the above article, when a file or folder is moved across volumes/partitions, it will inherit ACLs of the destination folder, therefore, before the advent of Google Drive for Desktop client, the trick which would fix the issue was:
- deleting the
.tmp.drivedownloadfolder; - creating a symbolic link to
.tmp.drivedownloadpointing to a folder located on another volume. For instance:mklink /d C:\drive\.tmp.drivedownload \\QNAP-TS231P\tmpDrive
Doing so, files from the Internet in Google Drive would download to the .tmp.drivedownload and moved to the corresponding local folder, however, as the .tmp.drivedownload folder was located on a different partition/volume, the file was correctly inheriting of ACLs set into the target folder as expected.
Unfortunately, all this is now broken since the introduction of Google Drive for Desktop client, which replaces good ol’ Backup & Sync, does not allow the above trick, as, once the symbolic link to .tmp.drivedownload is created, Google Drive for Desktop client will throw an error when attempting to synchronise a file or a folder from the cloud to the local computer

Further investigation into Google Drive for desktop logs will show an error, for example:
<<some data here>> failed with Status::GENERIC_ERROR
What would you try?