I guess I have something to add as a "wnidows caveat" and also it might even be related or the origin behind the issue OP is talking about (not tested though, just hypothesis).
Mounted drives can not be shared or have permissions altered. GUI will simply say the path does not exist.
This is fairly technical, but from what I understand the mount is created in a namespace that is somewhere above the SYSTEM's level and does not propagate down. Shares and permissions editing by an admin account presumably calls SYSTEM to make the changes. However, SYSTEM account can not see the path and thus fails.
(SYSTEM on Windows is equivalent of Linux root)
Run rclone mount from SYSTEM account (this can also help rclone read files with tricky permissions as an added benefit). This fixes the problem by registering the mount path in the SYSTEM namespace - and that will be visible to any other user + allow system to modify permissions and shares normally.
Part of the problem here is that accessing the SYSTEM account is not as simple as sudo on Windows. A lot of even advanced users think Aministrator is basically root, but that's not the case.
This can be accomplished in few ways - not all of which I have tried yet:
- Use Microsoft PStools with psexec -s -i to elevate yourself to SYSTEM account then mount (tested)
- Select SYSTEM account as the account to run under for task-scheduler or service (not tested, but I assume it would work fine)
...and probably more ways that I just don't know about =P
This probably is a worthwhile inclusion to documentation since it's a pretty technical problem with a non-obvious solution that blocks fairly common use-cases on Windows (like simply sharing a mounted drive on your network).
The reason I say it might be related to the OPs post is that the same namespace problem might be occurring on that elevated account. Not tested as I said, but seems plausible.