"rclone mount" running as Windows SYSTEM user: Cannot modify/overwrite existing file from local command line or remote client, even though creating a new file works

Help and Support
1

What is the problem you are having with rclone?

Summary: Overwriting or otherwise modifying an existing file on an rclone mount via a network share fails, even though creating a new file works.

Details:
On my computer acting as server (Windows 11 Pro x64, 22H2) I have an rclone mount running as SYSTEM user and share the mounted drive to the network for my login user there (user has Administrator privileges, sharing is with Full Control for that user). The share was created via Windows Explorer.

On my client computer (Windows 10 Pro x64, 21H2) I can connect to this share and create a new file on the share, e.g. the command
copy z:\Personal\netmap.cmd z:\Personal\netmap_copytest.cmd
works, if the file copytest.cmd does not yet exist (assuming the share is mounted as drive Z: on the client).

Important update: I'm not sure how I've missed this, but the problem also occurs, when trying this in a command line windows on the server computer. It isn't even necessary that the share has been created. Thus it appears to be related to rclone running as a SYSTEM user, rather than being a network sharing issue. I will fix the title of this topic.

However if the destination file does exist, the copy attempt fails. Similarly any other attempt to overwrite an existing file (e.g. editing an existing text file with notepad and trying to save the edit) fails.

It would be great, if someone could advise me, how I can get the full control actually working in this scenario.

Run the command 'rclone version' and share the full output of the command.

rclone v1.60.1
- os/version: Microsoft Windows 11 Pro 22H2 (64 bit)
- os/kernel: 10.0.22621.900 (x86_64)
- os/type: windows
- os/arch: amd64
- go/version: go1.19.3
- go/linking: static
- go/tags: cmount

FWIW my WinFSP install file was winfsp-1.12.22301.msi (version 2022.2).

Which cloud storage system are you using? (eg Google Drive)

Google Workspace

The command you were trying to run (eg rclone copy /tmp remote:tmp)

  1. The startup command to launch the main cmd file as SYSTEM user. This command is executed via a desktop shortcut with the option "Run as System Administrator" checked.
C:\SysinternalsSuite\psexec.exe -s -i cmd /C "start /min E:\rclone\rclone_mount_google_workspace_vault"

Note: The psexec utility is from Microsoft's Sysinternals Suite (see PsExec - Sysinternals | Microsoft Learn ).

  1. The main file rclone_mount_google_workspace_vault.cmd that is launched by the startup command:
    (Additional carets and line-breaks added for readability)
whoami
E:\rclone\rclone.exe mount google-workspace-vault: V: --drive-acknowledge-abuse ^
	--vfs-cache-mode full --vfs-cache-max-size 64G --vfs-write-back 30s ^
	--cache-dir E:\rclone\cache\google_workspace_rclone_vault --dir-cache-time 144h ^
	--daemon-timeout 599s ^
	--log-file=E:\rclone\rclone.log --log-level DEBUG ^
	--bwlimit 1400k
pause
exit

The rclone config contents with secrets removed.

[google-workspace]
type = drive
client_id = <redacted>.apps.googleusercontent.com
client_secret = <redacted>
scope = drive
token = <redacted>
team_drive = 

[google-workspace-vault]
type = crypt
remote = google-workspace:rcrypt_vault
password = <redacted>

A log from the command with the -vv flag

rclone.log (68.9 KB)

Due to the size of the log file rclone.log, I uploaded it, instead of pasting its content.
The log file was created with log-level DEBUG. The log file contains the "overwrite scenario, i.e. the target file already exists.

Please note for easier analysis: At the timestamp around 13:41:31 I executed the
copy z:\Personal\netmap.cmd z:\Personal\netmap_copytest.cmd
command and at around 13:41:36 I confirmed the overwrite prompt.

Als note: This log was created, when I still (wrongly) assumed that the issue was related to the network sharing, so it was done using a separate client computer. In the meantime I've figured out that this also happens, when trying this in a local command line windows on the server computer. If necessary I can provide a log for this as well.

1 Like
2

might try mounting to a folder, not a drive letter, as it does work around some issues.
something like
E:\rclone\rclone.exe mount google-workspace-vault: c:\mount

SYSTEM user is needed?

--daemon-timeout 599s
not supported on windows.

3

Thank you so much for your quick response. I just realized that the issue not only occurs on the network share (i.e. the client), but also on a command line windows on the server, where rclone is running, even if the network share hasn't even been created.

Not sure, how I've missed this. In any case I've updated the original post (including its title) to point this out.

Unfortunately that didn't make a difference. FWIW I've been running essentially the same command on my client computer locally for many months (using V: as a mount) without a problem. So it seems to be the fact that I'm running it now as SYSTEM user that causes the problem.

To the best of my knowledge it is needed, because I want to create a network share on this mount.

I've just tried again to run this under my local user (mounting to C:\mount). The copying works fine (even onto existing files), but when I tried to to create the network share on C:\mount, I got an error. So I'm afraid, I'll need it to work under the SYSTEM user.

Thanks, will remove this then. Though it doesn't seem to affect this particular issue.

4

Giving this topic a bump, as it is still unresolved:

  • TLDR: Even with the newer version 1.61.1 of rclone, a normal (or even elevated) user cannot change files on an rclone-mounted drive, when the "rclone mount" command is running under the SYSTEM user in Windows 11. (SYSTEM user is necessary to share the mounted drive via network share.)

  • The "-allow-other" (and/or "-allow-root") parameter that appear to address this issue in other OSes are not supported on Windows according to the docs.

At this point I am wondering, if this is either a bug (i.e. it is supposed to work in Windows, even without the "-allow-user" parameter) or a limitation of Windows. it would be great to get some further insight into this. I'm also happy to create an issue on github, if it helps.

5

Hi tangofan,

A quick tip (without having read all the details), have you checked the windows filesystem permissions as mentioned here:
https://rclone.org/commands/rclone_mount/#windows-filesystem-permissions

6

"not supported on Windows"

sorry, still not understand why you must use system user.
to share a rclone mount over a network, i have done this and documented the process in the forum.

as i remember, i mounted to a folder, not a dir and no need for system user.

not sure a good idea to share your admin account.
why not create a dummy user with standard permissions and have clients connect with that.

7

Ole, thank you for your response. I tried it with the highest permission level for files, but that unfortunately didn't work either. Still was worth a try.

1 Like
8

When I launch rclone mount as a regular user (non-elevated admin account) and then try to share the mounted drive or directory (I tried both cases interactively in Windows Explorer) I am getting an error, e.g. for the directory case (mounting to "C:\mount") I got the popup "An error occurred trying to share mount. The process cannot use the file because it is being used by another process. The shared resource was not created at this time.".

If you could point me to your documentation of the process that would be great, because it seems that there is a bit more involved to get it working.

9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.