How to invoke rclone config reconnect from the command-line

how can I invoke the rclone config reconnect REMOTE: command from the command line?

at present I have a script that send a couple of answers to rclone (first yes, then no) in order to get to the token submission phase, and then provide my own token there.
something goes wrong, though:

user@host ~$ rclone config reconnect REMOTE: << EOF
y
n
mytoken
EOF

Already have a token - refresh?
y) Yes (default)
n) No
y/n> Use auto config?
 * Say Y if not sure
 * Say N if you are working on a remote or headless machine
y) Yes (default)
n) No
y/n> 2020/05/29 20:21:53 Failed to read line: EOF

any help is appreciated. thanks!

1 Like

to be clear, the ideal would be to interface with rclone config reconnect with command-line parameters, not in an interactive run.
I haven't found info about that, though...

You probably want this flag

 --auto-confirm   If enabled, do not request console confirmation.

Which I think will do the right thing for you without needing to pipe in the input.

I'll try and let you know! thanks!

1 Like

unfortunately, this is not what I'd like to do.

until my problem with Box.com tokens keep expiring? is solved -- either I'm doing something wrong there, or it's a bug -- I have devised a way to automatically reauthorize my Box logins.

I'd like to use a combo of rclone authorize and rclone config reconnect to manually repeat the oauth process.
I was trying to run: 1) rclone authorize box --auth-no-open-browser to get a local webserver url for oath redirection, 2) manually opening the browser and typing user/pass and granting the oauth, 3) inserting the token in rclone config reconnect.

the global flag you suggested prevents me from using this process: ideally, I'd imagine a flag to do everything but avoid rclone opening the browser on its own but I haven't found it.
I've also taken a look at the remote parameters such as config_refresh_token=false and config_is_local=false but neither of those use cases are helpful.

I'd like to, ideally, execute a:
rclone config reconnect REMOTE: --auto-confirm --dont-open-browser

any suggestions? thanks

If you just want to set the token in the config file you can use rclone config update

Get the token first with rclone authorize

I don't think you actually need to run rclone config reconnect in this case.

great suggestion.
I was getting dizzy between the various rclone commands to do the same thing.

this should work, then:

  1. rclone authorize box --auth-no-open-browser (to start up the auto config),
  2. browser logic (I'm using puppeteer to automate this), get the token,
  3. rclone config update MYBOX token '{"access_token":"XXXXX","token_type":"bearer","refresh_token":"YYYYY","expiry":"2020-05-30T19:31:13.629562253-07:00"}'

except that it doesn't. :confused:
while doing 3), rclone seems to want to repeat the whole process again:

user@host ~$ rclone config update MYBOX token '{"access_token":"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX","token_type":"bearer","refresh_token":"YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY","expiry":"2020-05-30T19:31:13.629562253-07:00"}'

Remote config
Already have a token - refresh?
Auto confirm is set: answering Yes, override by setting config parameter config_refresh_token=false
Use auto config?

  • Say Y if not sure
  • Say N if you are working on a remote or headless machine
    Auto confirm is set: answering Yes, override by setting config parameter config_is_local=false
    If your browser doesn't open automatically go to the following link: http://127.0.0.1:53682/auth?state=ZZZZZZZZZ
    Log in and authorize rclone for access
    Waiting for code...

which is not what I'd like to do!
am I missing another piece of the puzzle?

many thanks for the help.

Notice that rclone is giving you a hint as to what you need to do

Auto confirm is set: answering Yes, override by setting config parameter config_refresh_token=false

So if you try this

rclone config update remotename token "token data" config_refresh_token false

I think (hope) it will finally do what you want!

1 Like

okay, this works:

  1. rclone authorize box --auth-no-open-browser
  2. manual/automated browser logic to get the token
  3. rclone config update MYBOX token "MYTOKEN" config_refresh_token false

NOTE: this flow has the disadvantage that the remote is also modified with config_refresh_token=false, which is not really what I want.
also, rclone config update MYBOX config_refresh_token true does not reset the flag as it was, but starts the oauth process again.

in any case, I would suggest to make sure that every interactive command has an exact counterpart for command-line execution, so the user does not have to reinvent the wheel depending on how the interface to rclone happens.

regarding my issues, I'll still try and understand what's going awry with refresh tokens, but in case I need it I now know how to automate the token refreshing process. thanks!

Yes the config system kind of evolved and isn't as friendly as it could be for auto configuration.

The magic config_ strings are an attempt to make it better but I think it is a poor interface...

Any suggestions appreciated!

1 Like

yeah, no worries!
it's quite difficult as it is to keep track of changes in the docs, let alone enhance the entire user interface.

my suggestion is, roughly, to make sure to have a non-interactive rclone command, for each and every rclone command.

I was, and still am, pretty confused by the rclone docs -- another example of my doubts was How to create new "crypt" remote from command line.
also, if I may be honest, the "global flags" page is not really helpful, because it coalesces stuff together that not necessarily belongs together, and makes the user go there fishing for possible parameters.
it would be a lot more readable if all the flags applicable to a certain command were in its doc page.
IMHO!

The basic config stuff works reasonably well, but each backend is entitled to have a config hook which runs code. These config hooks are the ones which renew tokens and ask the user stuff. They are potentially unique to each backend - for example the google drive one configures the token then asks if you want to configure a team drive.

Making a uniform command line interface for those isn't something I've figured out yet. I could make them use the same configuration machinery as the main configuratiion - that might work - then at least all the possible parameters would be documented in advance even if not all of them were relevant.

Ideally there needs to be a bit of back and forth - the google backend needs to get the token before it can ask you to choose from a list of team drives.

Potentially I could do

  • define all the possible questions in advance so they go in the docs
  • have a config state so you can have more than one config callback and you need to provide the number of the one you want next
  • when rclone returns from the config and there are still questions to ask, then return a JSON blob with the question(s) in and a state for the config to use on the next call...

You are right, rclone shouldn't really be storing the config_magic strings in the config, but there is no-where else to put them at the moment.

I'm waaay out of my depth, here, but I really thank you for elaborating.
I feel like I've graduated from noob to user -- maybe in the future be able to help as a power user.

in the mean time, I really hope more experienced users will chime in with their thoughts!

Sorry that was a bit of a brain dump wasn't it! I'll copy it into my TODO file and we can forget it ever happened :wink:

2 Likes

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