There is something you might want to know. The server allows sftp only and in an sftp jail only; not any ftp and not any ssh login. I do not know if this has any relevance; I am just a fool here. But what has this go to do with a network drive that we cannot remove.
The ugly method below to go round the rclone bug is not in rclone nor itâs documentation. I tried two methods my self that failed and later were suggested in this forum. The first failed method was the use of a command shown on the top bar of Windows Explorer to disconnect a network drive. The second failed method was disconnecting the drive with the following failed command:
net user fort_tu1: /delete
and this way
net user 208.113.134.46: /delete
The method that worked for me, arrived at with agony, had these steps:
(a) Shut down the computer. (Power down.)
(b) Disconnect the network cable manually. (Disconnecting the network using any MS Windows methods did not work.)
(c) Power up the computer without connecting the cable.
(d) Login.
(e) Start Windows Explorer.
(f) Click with the right mouse button on the network drive in question. (When I did that without this procedure the system went on as if looking for the drive and came back with a pop-up message saying that the drive could not be connected, and I could not go on to the next step; every time.)
(g) Select âDisconnect Driveâ from the selections that appear. At this stage the network drive disappears.
(h) Connect the network cable and get on with your work.
You wanted the evidence of a bug; this is all the evidence I can give. I am not competent enough to do any debugging to provide other evidence. However I am willing to help somebody who knows rclone and Windows to do the debugging.
If rclone cannot remove a drive it created then to my mind that is a bug; no matter what rclone command was used (or misused) to create the drive. I could not find in the rclone documentation any rclone or Windows command or method that would remove the drive rclone created.
rclone apparently did something neither rclone nor Windows can handle gracefully. Is there an rclone command or even a Windows command to remove the drive created by an rclone command without the trouble I have had to go through? If there is such thing then the issue is not a bug and rclone is a sound tool that one can trust and is not dangerous.
I am not a Windows guru and I should not have to be a Windows guru to connect or disconnect a network drive using rclone
Has anybody used âSyncthingâ?
If you type rclone delete myVeryIportantFile would you blame rclone? It is the same here. You attempted to access some network location and your OS tries to make your life easier and remembers it for later. It has nothing to do with rclone. There was never any network drive connected.
There isn't any bug in rclone. At least here:)
I glanced at "rclone sync", it does look more appropriate than "rclone mount"; assuming that it shows synced directories in Windows Explorer (maybe with winfsp).
rclone IS powerful. Can one compile the code and exclude commands not wanted. If I only use "rclone sync", I would not need "rclone mount" and the rest compiled in. Perhaps each of the rclone commands can have its little application. I think many would probably welcome that. One can still use separatly compiled rclone commands.
Is this a troll post or are you actually serious?
Dose SFTP ârclone mountâ work with a regular SFTP server that comes with Ubuntu 22.04, rather than the ârclone serveâ? Does it require the ârclone serveâ like ârclone syncâ does?
The client rclone config file is now:
[fort_tu1]
type = sftp
host = 208.113.134.46
user = tu1
key_pem = C:\Users\justme\.ssh\id_ed25519_tu1.pem
ssh = ssh -i C:\Users\justme\.ssh\id_ed25519_tu1.pem tu1@208.113.134.46
known_hosts_file = C:\Users\justme\.ssh\known_hosts
shell_type = none
skip_links = true
idle_timeout = 10m0s
[fort_tu1_new]
type = sftp
host = 208.113.134.46
user = tu1
key_file = C:\Users\justme\.ssh\id_ed25519_tu1
ssh = ssh -i C:\Users\justme\.ssh\id_ed25519_tu1 tu1@208.113.134.46
shell_type = none
skip_links = true
idle_timeout = 10m0s
[fort_tu1_new_2]
type = sftp
host = 208.113.134.46
user = tu1
key_file = C:\Users\justme\.ssh\id_ed25519_tu1
ssh = ssh -i C:\Users\justme\.ssh\id_ed25519_tu1 tu1@208.113.134.46
idle_timeout = 10m0s
The SFTP server is the server that comes with Ubuntu 22.04. This is the result a mount attempt (on Windows 10):
C:\Users\justme>rclone mount fort_tu1_new: Z:
2024/03/06 09:39:40 NOTICE: fort_tu1_new: --sftp-ssh is in use - ignoring user/host/port from config - set in the parameters to --sftp-ssh (remove them from the config to silence this warning)
2024/03/06 09:41:02 Failed to create file system for "fort_tu1_new:": NewFs: couldn't initialise SFTP: error receiving version packet from server: server unexpectedly closed connection: unexpected EOF
C:\Users\justme>
The SFTP server allows SFTP with no SSH login and users are in an SFTP Jail. This is what happens if the user tries to do an SSH login
C:\Users\justme>ssh -i C:\Users\justme\.ssh\id_ed25519_tu1 tu1@208.113.134.46
This service allows sftp connections only.
Connection to 208.113.134.46 closed.
C:\Users\justme>
Where am I wrong if ârclone mountâ should be working? It looks to me like rclone needs to do ssh login. If that is the case then rclone will not work for my application. For security reasons, users are not allowd ssh login and are confined to an SFTP Jail. Please advise.
rclone works with any sftp server. It does not require rclone serve
If you have any specific issues please create new thread. This one is originally about something very different.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.