Syntax for config-less operation?

I understand that running rclone without a config file at all, may be possible, based on this topic:

Can rclone be run solely with command line options ? (no config, no env vars)

If that's possible, how? I've tried numerous combinations of flags and haven't been able to get it to work when no config file exists, including but not limited to:

--sftp-host string 
--sftp-port string
--sftp-user string
--sftp-pass string

Instead, rclone always seems to immediately complain that a configuration doesn't yet exist.

Also, it's not clear what the full rclone syntax should be when using these flags. Consider the following command for example:

rclone sync /source/folder SERVER:/target/folder

The string "SERVER" identifies an arbitrary configuration name that the user must have already set up with rclone config, not a network address and/or protocol. Instead, the network address and protocol are stored in the config file, with a configuration matching that name.

  • Question 1: So...if network address, protocol, username, etc. can be specified with command-line flags (e.g. --sftp-*), how do you tell rclone which is the remote...source or target? (Or both different remote hosts?)

What is your rclone version (output from rclone version)

rclone v1.49.3
- os/arch: linux/amd64
- go version: go1.12.9

Which OS you are using and how many bits (eg Windows 7, 64 bit)

Distro: Ubuntu 18.04.3 LTS
Kernel: 5.0.0-29-generic

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

None. SFTP over internal LAN.

I think you are maybe confusing two different things together:

  • Using rclone to connect and do operations on an SFTP server
  • Using rclone to serve as an SFTP server

Of course if you want it is possible to do both, and have them work together - but you'd have to do both. I don't think a single command will do this (even though you could make a one-line multicommand for sure).

How to set up the SFTP:

How to connect rclone with an SFTP:

I don't think defining a remote to use to connect is necessary. Rclone has a few built-in modes it can use directly (like the local filesystem - you don't need to specify a remote for that). I think this applies for SFTP too, and rather than set a destination as MyFSTPserver:\Myfiles you can probably just something like sftp:\Myfiles (same synatx as you'd use to access an SFTP server in any other application like a browser or whatever - note I did't check that syntax is accurate, only for illustration).

But the alternative is that you can create and destroy remote configs on the fly. Check out
(and the corresponding delete)
If you just put these as part of your script you can make anything you need then and there from the commandline, and then you can call the remote anything you wish and refer to it like that in your sync command.

Try your hand at that and see if you can get 2 terminal windows working together as client and server - and if you can do that then it's fairly trivial to script it into a custom combo-command if this is something you use regularly. Got to warn you though , I am fairly noob with bash scripting :stuck_out_tongue:

Thanks for the feedback.

I'm not confusing remote and local (I definitely don't want to run an rclone server and the back-end only has OpenSSH [and therefore also SFTP])...though I easily might be confused about what option flags are relevant for client and which for server!

I did try that (e.g. sftp:tartet-folder, ssh:tartet-folder, sftp://tartet-folder, sftp:/target-folder, sftp://host:/target-folder, etc.), and various other permutations and flags, but so far no dice.

It's good to know that rclone config create & delete are things. Somehow I missed that. That's definitely a "plan B"! Thanks.

But since my script (which is complex...and already written and tested and soon to share on github) is designed to be generic, ignorant of what the client has going on, free of too many dependencies (other than the existence of a minimum version of rclone), and ideally not too intrusive, I'd rather avoid any local config files if necessary. It's designed to work sort of like rsync in terms of specifying a remote host for source or target (or all local), given nothing more than:

  • Reachable remote address
  • Port
  • Username
  • Password via prompt

And like rsync, if the remote port is 22 and the remote username is the same as current local, then all you need is the remote address. The protocol is assumed to be ssh. (Likewise, my script has similar defaults, and assumes ssh's built-in sftp server.)

If I have to create a throwaway local config to accomplish that, I guess there are worse problems in the world.

If it matters, the purpose of the script:

  • Focus on mirroring only, where source structure gets renamed/reorganized often.
  • Provides a --prioritize flag for large data sets and/or slow transfer speeds, which makes multiple passes (without prompting for credentials again), prioritizing the transfer of newest, smallest, and digital media originals (e.g. camera raw) first.
  • Encapsulates rclone with a set of flags optimized for that use-case. Exposes a few of it's own flags. Allows user to pass-through additional rclone flags at their own risk (attempts to catch the most obvious conclicts).

Ok, I think I mis-understood your intent a little.

This should be what you need:

rclone copy --sftp-host :sftp:path/to/dir /tmp/dir

This will basically define a SFTP-remote in-line with the command. Note the very spesifc syntax there in :sftp: and that this is a protocol (or I guess more spesifically a remote-type), not a remote name.

That example will only work on a default port, with anonymous login ect.
You probably also need to add:
--sftp-port (maybe not..)
(there's an optional flag to set password to be prompted instead if you want that, see docs)

This should then allow you to do rclone operations directly to an existing sftp-server, and it's a single command. Mark the answer if this solves it for you :slight_smile:

1 Like

Fantastic, thanks!

1 Like

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