When I run rclone mount on Windows 10 the "drive" permissions look like this:
All three users have only the special persmissions checked. When I got into advanced and try to modify or add other users I can't.
Is there a way to add other users to those permission, or change the permissions on the shown users? My goal would be to make it look something like this:
Using rclone v1.48.0
- os/arch: windows/amd64
- go version: go1.12.3
Can you better define what happens when you say you "can't" ?
Is there an error? Does windows behave abnormally when trying this on the mounted drive but otherwise behaves normally? Or is there a spesific thing that fails?
If windows errors or appears to hang I have a hunch what it may be: Basically the same problem as you get if you try to network-share the drive. If you try that you get an error that you can't and that the location doesn't exist. I recently did some digging to understand this problem and how to fix it - but since the explanation may be a little long I will hear what you reply before i start to rant on in a potentially wrong direction =P
The mount behaves normally if I use it from my computer the issue I’m having the is that when I try to access it over SFTP (using Buru Server) i can’t access the mount. As for the permissions when I go to advanced and add user “SYSTEM” once I hit apply it exits and the permissions remain the same. Here is the weird thing if I use Rebex SFTP server which is a really simple server I can access the mount. Main difference between the two is that Buru runs as a service on windows under my user name whole Rebex is just an executable. The permission route was just something I wanted to try and see if it made a difference. The reason I don’t stick to Rebex is that it doesn’t have any kind of IP blacklisting/whitelisting.
Well it sounds like it may be related to what I was talking about, so I will explain some details.
Since the mount is essentially an emulated harddrive and not real hardware, if you mount it as your user (even as an admin) that driveletter/parth will only exist in the namespace of your user. This is normally not a problem - but when you try to do stuff like set up a share (and this probably also would extend to editing permissions) what I think happens is that it is actually the SYSTEM account that is called to make the changes. And here is the problem - the SYSTEM account has no idea that anything exists in the mount path because that name never got registered at it's level. So the result is windows may act weirdly, throw an error or appear to do nothing as the request is nonsensical to SYSTEM and shouldn't normally be a situation that happens.
This may sound very technical, and it kind of is, but the solution is relatively simple: Start the mount using the SYSTEM account. This will register the path at a lower level so both SYSTEM and all user accounts should then be aware of it. When you do this the problems with network sharing disappear, and I suspect your permissions problem is related.
The second problem to tackle then is how the heck do you run anything as SYSTEM? There isn't a "sudo" in windows like in Linux. There are a few ways you can accomplish this:
- Using PStools from microsoft you can effectively run commands as SYSTEM if you (from admin elevated CMD) use psexec -i -s path\to\mymountscript.bat This pretty much works similar to a sudo on Linux. To test that it works you can psexec -i -s cmd.exe and then run the whoami command. It should reply that you are running the cmd as SYSTEM then.
- In task scheduler you can set tasks to run under other accounts, including SYSTEM, this should work too but I haven't tested it. Don't see why it wouldn't work.
- If you run your mount as a service, I think that also runs under SYSTEM (or can at least be set to use SYSTEM).
If you just want to do a quick test to see if this fixes your problem then the PStools thing is probably the fastest. just google PStools to find the microsoft download. Let me know if you need more help.
So I tried the PStools route and like you said it fixed the issue. I can now see the mount through my SFTP server and access the files no problem. The only hiccup I ran into is that when running rclone under psexec the default config path changes so I had to add the --config flag to the bat file. As for the permissions it won't let me add or remove users or change the permissions for the two users that are added which are Everyone and System.
Great to hear it worked! I also learned something new here, so thanks for sharing your results
The default config location changing is just a result of it being under a different user. This is to be expected. Note that if there is an rclone config present in the same folder as the rclone.exe then this will always be used no matter what. I find this very convenient and it prevents me from accidentally using wrong configs if I manually run rclone commands and forget to add a config location. Try it You can just copy your existing config file there.
As for changing the permissions, since it was SYSTEM that set these it may also be needed to change them. Your regular admin account may not have the permission for it. If you can identify what executable is actually used to launch that dialogue window - or you google search and find how to set it via cmd (which I am certain is possible), then you should be able to use the same trick with PStools to get this done I bet.
EDIT: this might be along the lines of what you need to do it easily
The Everyone user might be added from the --allow-other option, or windows might just be adding that as default, not sure. In any case, if you can get access to alter the permissions you should just be able to remove it in any case.
Here is a probably easier way to set permissions through SYSTEM account.
use psexec-i -s cmd.exe
from there run Compmgmt.msc
Compmgmt.msc is a GUI screen that will let you fiddle with share and security permissions (but I think the disk may need to have an existing share to show up on the list? might need to set one temporarily). Running under SYSTEM should give you the access you need, and you don't have to figure out the commandline stuff to do it (even though that looks to be relatively simple too from that other link)
I'm sure there is a more direct .msc you can call to get the exact screen you need, but I don't know these by heart and you can probably goolge them as well as I can
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.