hello to all,
webpage https://rclone.org/commands/rclone_mount/ states:
"Note that drives created as Administrator are not visible by other accounts (including the account that was elevated as Administrator). So if you start a Windows drive from an Administrative Command Prompt and then try to access the same drive from Explorer (which does not run as Administrator), you will not be able to see the new drive."
here is a very simple workaround for a very annoying problem.
while the solution offered that the rclone webpage, using nssm is a hassle and only solves the issue for rclone mount, there is a solution for all apps, a single registry change.
for sure, many users will benefit from a simple registry change and not just for winfsp workaround.
i enabled the regedit many years ago. long before i started using rclone.
i understand micro$soft's logic to implementing this feature.
as a power user, it is real pain in the tuckus!
i need to be able to create a net share, no matter how it is created, and access it from
--- the command line
--- cmd scripts
--- python editor and debugger
--- windows explorer
--- double commander
--- however, whenever, whatever.
if you do update the docs, note that the computer must be rebooted after the regedit.
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).
Problem description:
Mounted drives can not be shared or have permissions altered. GUI will simply say the path does not exist.
Cause:
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)
Solution/Workaround:
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.
I just got a reply bulls23ant regarding an earlier post touching this subject and he has confirmed for me that the service-under-SYSTEM route works fine also. If his method (which I have requested) is fairly straight-forward - or if I can find a streamlined way myself - then I'll try to include that in a WIKI article on the topic.
The best current place I can see for it would be the github wiki yes. In the long-term I don't think it's a good idea to include every caveat and workaround for every situation in the main documentation - as it would just bloat and become not very user-friendly. Such things are better linked as useful resources - like say a category of windows-spesific stuff.
That said - my honest opinion of the github wiki and other resources there is that it's kind of hidden away in a corner and not very visible to most visitors I bet. Just github itself is probably intimidating to the more casual users, and even I missed a lot of the stuff that was already there. The formatting is also pretty rudimentary (although I don't know the limits of the github system)
An eventual goal may be to re-format some of the information there into a more traditional standalone wiki-page with menus and subsections - a main jumping off point for knowledge resources. I'd be willing to contribute to it - but I'm not familiar with how to set one up. I suspect it's not that hard and it's probably just a matter of using a stock template and adding some category structure to it. Just a though for the future... at least anything added to the current wiki will not be lost going forward
It is possible to turn forum posts into wiki posts and store info like that. I haven't investigated how to do that and I'm not sure it is the right thing to do!
That is a good point...
I wonder if I should mirror the rclone wiki to rclone.org? I could probably write a script to do that quite easily. I'd keep the editing on github.
Or I could install some wiki software. This is my least favourite option as I'm trying not to maintain too much stuff!
Probably. It mainly just needs more structure and visibility. Visibility and user-friendliness is a big deal if you want it to grow organically from the user-base. Some categories wouldn't hurt - especially as the content grows.
I don't really know the limitations we work within on github ect. but IMO the optimal user experience would probably be to have the wiki be it's own button on the top bar of the rclone.org site - and use the drop-down menu on that to springboard you into the most common categories. That's just my 2 cent anyway.
