neulab/tldr huggingface dataset:
--gphotos-client-secret OAuth Client Secret.
• Env Var: RCLONE_GPHOTOS_CLIENT_SECRET
--gphotos-read-only Set to make the Google Photos backend read only.
If you choose read only then rclone will only request read only access to your photos, otherwise rclone will request full access.
• Config: read_only
• Env Var: RCLONE_GPHOTOS_READ_ONLY
Advanced options Here are the advanced options specific to google photos (Google Photos).
--gphotos-token OAuth Access Token as a JSON blob.
• Env Var: RCLONE_GPHOTOS_TOKEN
--gphotos-auth-url Auth server URL.
• Env Var: RCLONE_GPHOTOS_AUTH_URL
--gphotos-token-url Token server url.
• Env Var: RCLONE_GPHOTOS_TOKEN_URL
--gphotos-read-size Set to read the size of media items.
Normally rclone does not read the size of media items since this takes another transaction.  This isn't necessary for syncing.  However rclone mount needs to know the size of files in advance of reading them, so setting this flag when using rclone mount is recommended if you want to read the media.
• Config: read_size
• Env Var: RCLONE_GPHOTOS_READ_SIZE
--gphotos-start-year Year limits the photos to be downloaded to those which are uploaded after the given year.
• Config: start_year
• Env Var: RCLONE_GPHOTOS_START_YEAR
• Default: 2000
--gphotos-include-archived Also view and download archived media.
By default rclone does not request archived media.  Thus, when syncing, archived media is not visible in directory listings or transferred.
Note that media in albums is always visible and synced, no matter their archive status.
With this flag, archived media are always visible in directory listings and transferred.
Without this flag, archived media will not be visible in directory listings and won't be transferred.
• Config: include_archived
• Env Var: RCLONE_GPHOTOS_INCLUDE_ARCHIVED
--gphotos-encoding This sets the encoding for the backend.
• Env Var: RCLONE_GPHOTOS_ENCODING
Limitations Only images and videos can be uploaded.  If you attempt to upload non videos or images or formats that Google Photos doesn't understand, rclone will upload the file, then Google Photos will give an error when it is put turned into a media item.
Note that all media items uploaded to Google Photos through the API are stored in full resolution at "original quality" and will count towards your storage quota in your Google Account.  The API does not offer a way to upload in "high quality" mode..
rclone about is not supported by the Google Photos backend.  Backends without this capability cannot determine free space for an rclone mount or use policy mfs (most free space) as a member of an rclone union remote.
Downloading Images When Images are downloaded this strips EXIF location (according to the docs and my tests).  This is a limitation of the Google Photos API and is covered by bug #112096115 (https://issuetracker.google.com/issues/112096115).
The current google API does not allow photos to be downloaded at original resolution. This is very important if you are, for example, relying on "Google Photos" as a backup of your photos. You will not be able to use rclone to redownload original images. You could use 'google takeout' to recover the original photos as a last resort
Downloading Videos When videos are downloaded they are downloaded in a really compressed version of the video compared to downloading it via the Google Photos web interface.  This is covered by bug #113672044 (https://issuetracker.google.com/issues/113672044).
Duplicates If a file name is duplicated in a directory then rclone will add the file ID into its name.  So two files called file.jpg would then appear as file {123456}.jpg and file {ABCDEF}.jpg (the actual IDs are a lot longer alas!).
If you upload the same image (with the same binary data) twice then Google Photos will deduplicate it.  However it will retain the filename from the first upload which may confuse rclone.  For example if you uploaded an image to upload then uploaded the same image to album/my_album the filename of the image in album/my_album will be what it was uploaded with initially, not what you uploaded it with to album. In practise this shouldn't cause too many problems.
Modified time The date shown of media in Google Photos is the creation date as determined by the EXIF information, or the upload date if that is not known.
This is not changeable by rclone and is not the modification date of the media on local disk.  This means that rclone cannot use the dates from Google Photos for syncing purposes.
Size The Google Photos API does not return the size of media.  This means that when syncing to Google Photos, rclone can only do a file existence check.
It is possible to read the size of the media, but this needs an extra HTTP HEAD request per media item so is very slow and uses up a lot of transactions.  This can be enabled with the --gphotos-read-size option or the read_size = true config parameter.
If you want to use the backend with rclone mount you may need to enable this flag (depending on your OS and application using the photos) otherwise you may not be able to read media off the mount.  You'll need to experiment to see if it works for you without the flag.
Albums Rclone can only upload files to albums it created.  This is a limitation of the Google Photos API (https://developers.google.com/photos/library/guides/manage-albums).
Rclone can remove files it uploaded from albums it created only.
Deleting files Rclone can remove files from albums it created, but note that the Google Photos API does not allow media to be deleted permanently so this media will still remain.  See bug #109759781 (https://issuetracker.google.com/issues/109759781).
Rclone cannot delete files anywhere except under album.
Deleting albums The Google Photos API does not support deleting albums - see bug #135714733 (https://issuetracker.google.com/issues/135714733).
Hasher (EXPERIMENTAL) Hasher is a special overlay backend to create remotes which handle checksums for other remotes.  It's main functions include: - Emulate hash types unimplemented by backends - Cache checksums to help with slow hashing of large local or (S)FTP files - Warm up checksum cache from external SUM files
Getting started To use Hasher, first set up the underlying remote following the configuration instructions for that remote.  You can also use a local pathname instead of a remote.  Check that your base remote is working.
Let's call the base remote myRemote:path here.  Note that anything inside myRemote:path will be handled by hasher and anything outside won't.  This means that if you are using a bucket based remote (S3, B2, Swift) then you should put the bucket in the remote s3:bucket.
Now proceed to interactive or manual configuration.
Interactive configuration Run rclone config:
No remotes found - make a new one n) New remote s) Set configuration password q) Quit config n/s/q> n name> Hasher1 Type of storage to configure. Choose a number from below, or type in your own value [snip] XX / Handle checksums for other remotes \ "hasher" [snip] Storage> hasher Remote to cache checksums for, like myremote:mypath. Enter a string value. Press Enter for the default (""). remote> myRemote:path Comma separated list of supported checksum types. Enter a string value. Press Enter for the default ("md5,sha1"). hashsums> md5 Maximum time to keep checksums in cache. 0 = no cache, off = cache forever. max_age> off Edit advanced config? (y/n) y) Yes n) No y/n> n Remote config -------------------- [Hasher1] type = hasher remote = myRemote:path hashsums = md5 max_age = off -------------------- y) Yes this is OK e) Edit this remote d) Delete this remote y/e/d> y
Manual configuration Run rclone config path to see the path of current active config file, usually YOURHOME/.config/rclone/rclone.conf.  Open it in your favorite text editor, find section for the base remote and create new section for hasher like in the following examples:
[Hasher1] type = hasher remote = myRemote:path hashes = md5 max_age = off
[Hasher2] type = hasher remote = /local/path hashes = dropbox,sha1 max_age = 24h
Hasher takes basically the following parameters: - remote is required, - hashes is a comma separated list of supported checksums (by default md5,sha1), - max_age - maximum time to keep a checksum value in the cache, 0 will disable caching completely, off will cache "forever" (that is until the files get changed).
Make sure the remote has : (colon) in.  If you specify the remote without a colon then rclone will use a local directory of that name.  So if you use a remote of /local/path then rclone will handle hashes for that directory.  If you use remote = name literally then rclone will put files in a directory called name located under current directory.
Usage Basic operations Now you can use it as Hasher2:subdir/file instead of base remote.  Hasher will transparently update cache with new checksums when a file is fully read or overwritten, like:
rclone copy External:path/file Hasher:dest/path
rclone cat Hasher:path/to/file > /dev/null
The way to refresh all cached checksums (even unsupported by the base backend) for a subtree is to re-download all files in the subtree.  For example, use hashsum --download using any supported hashsum on the command line (we just care to re-read):
rclone hashsum MD5 --download Hasher:path/to/subtree > /dev/null
rclone backend dump Hasher:path/to/subtree
You can print or drop hashsum cache using custom backend commands:
rclone backend dump Hasher:dir/subdir
rclone backend drop Hasher:
Pre-Seed from a SUM File Hasher supports two backend commands: generic SUM file import and faster but less consistent stickyimport.
rclone backend import Hasher:dir/subdir SHA1 /path/to/SHA1SUM [--checkers 4]
Instead of SHA1 it can be any hash supported by the remote.  The last argument can point to either a local or an other-remote:path text file in SUM format.  The command will parse the SUM file, then walk down the path given by the first argument, snapshot current fingerprints and fill in the cache entries correspondingly.  - Paths in the SUM file are treated as relative to hasher:dir/subdir.  - The command will not check that supplied values are correct.  You must know what you are doing.  - This is a one-time action.  The SUM file will not get "attached" to the remote.  Cache entries can still be overwritten later, should the object's fingerprint change.  - The tree walk can take long depending on the tree size.  You can increase --checkers to make it faster.  Or use stickyimport if you don't care about fingerprints and consistency.
rclone backend stickyimport hasher:path/to/data sha1 remote:/path/to/sum.sha1
stickyimport is similar to import but works much faster because it does not need to stat existing files and skips initial tree walk.  Instead of binding cache entries to file fingerprints it creates sticky entries bound to the file name alone ignoring size, modification time etc.  Such hash entries can be replaced only by purge, delete, backend drop or by full re-read/re-write of the files.
Configuration reference Standard options Here are the standard options specific to hasher (Better checksums for other remotes).
--hasher-remote Remote to cache checksums for (e.g.  myRemote:path).
• Env Var: RCLONE_HASHER_REMOTE
--hasher-hashes Comma separated list of supported checksum types.
• Config: hashes
• Env Var: RCLONE_HASHER_HASHES
• Type: CommaSepList
• Default: md5,sha1
--hasher-max-age Maximum time to keep checksums in cache (0 = no cache, off = cache forever).
• Config: max_age
• Env Var: RCLONE_HASHER_MAX_AGE
Advanced options Here are the advanced options specific to hasher (Better checksums for other remotes).
--hasher-auto-size Auto-update checksum for files smaller than this size (disabled by default).
• Config: auto_size
• Env Var: RCLONE_HASHER_AUTO_SIZE
Backend commands Here are the commands specific to the hasher backend.
drop Drop cache
rclone backend drop remote: [options] [<arguments>+]
Completely drop checksum cache.  Usage Example: rclone backend drop hasher:
dump Dump the database
rclone backend dump remote: [options] [<arguments>+]
Dump cache records covered by the current remote
fulldump Full dump of the database
rclone backend fulldump remote: [options] [<arguments>+]
Dump all cache records in the database
import Import a SUM file
rclone backend import remote: [options] [<arguments>+]
Amend hash cache from a SUM file and bind checksums to files by size/time.  Usage Example: rclone backend import hasher:subdir md5 /path/to/sum.md5
stickyimport Perform fast import of a SUM file
rclone backend stickyimport remote: [options] [<arguments>+]
Fill hash cache from a SUM file without verifying file fingerprints. Usage Example: rclone backend stickyimport hasher:subdir md5 remote:path/to/sum.md5
Implementation details (advanced) This section explains how various rclone operations work on a hasher remote.
Disclaimer. This section describes current implementation which can change in future rclone versions!.
Hashsum command The rclone hashsum (or md5sum or sha1sum) command will:
1. if requested hash is supported by lower level, just pass it.
2. if object size is below auto_size then download object and calculate requested hashes on the fly.
3. if unsupported and the size is big enough, build object fingerprint (including size, modtime if supported, first-found other hash if any).
4. if the strict match is found in cache for the requested remote, return the stored hash.
5. if remote found but fingerprint mismatched, then purge the entry and proceed to step 6.
6. if remote not found or had no requested hash type or after step 5: download object, calculate all supported hashes on the fly and store in cache; return requested hash.
Other operations • whenever a file is uploaded or downloaded in full, capture the stream to calculate all supported hashes on the fly and update database
• server-side move will update keys of existing cache entries
• deletefile will remove a single cache entry
• purge will remove all cache entries under the purged path
Note that setting max_age = 0 will disable checksum caching completely.
If you set max_age = off, checksums in cache will never age, unless you fully rewrite or delete the file.
Cache storage Cached checksums are stored as bolt database files under rclone cache directory, usually ~/.cache/rclone/kv/.  Databases are maintained one per base backend, named like BaseRemote~hasher.bolt.  Checksums for multiple alias-es into a single base backend will be stored in the single database.  All local paths are treated as aliases into the local backend (unless crypted or chunked) and stored in ~/.cache/rclone/kv/local~hasher.bolt.  Databases can be shared between multiple rclone processes.
HDFS (https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop- hdfs/HdfsDesign.html) is a distributed file-system, part of the Apache Hadoop (https://hadoop.apache.org/) framework.
Paths are specified as remote: or remote:path/to/dir.
No remotes found - make a new one n) New remote s) Set configuration password q) Quit config n/s/q> n name> remote Type of storage to configure. Enter a string value. Press Enter for the default (""). Choose a number from below, or type in your own value [skip] XX / Hadoop distributed file system \ "hdfs" [skip] Storage> hdfs ** See help for hdfs backend at: https://rclone.org/hdfs/ **
hadoop name node and port Enter a string value. Press Enter for the default (""). Choose a number from below, or type in your own value 1 / Connect to host namenode at port 8020 \ "namenode:8020" namenode> namenode.hadoop:8020 hadoop user name Enter a string value. Press Enter for the default (""). Choose a number from below, or type in your own value 1 / Connect to hdfs as root \ "root" username> root Edit advanced config? (y/n) y) Yes n) No (default) y/n> n Remote config -------------------- [remote] type = hdfs namenode = namenode.hadoop:8020 username = root -------------------- y) Yes this is OK (default) e) Edit this remote d) Delete this remote y/e/d> y Current remotes:
Name                 Type ====                 ==== hadoop               hdfs
See all the top level directories
rclone ls remote:directory
Sync the remote directory to /home/local/directory, deleting any excess files.
rclone sync -i remote:directory /home/local/directory
Setting up your own HDFS instance for testing You may start with a manual setup (https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop- common/SingleCluster.html) or use the docker image from the tests:
If you want to build the docker image
git clone https://github.com/rclone/rclone.git cd rclone/fstest/testserver/images/test-hdfs docker build --rm -t rclone/test-hdfs .
Or you can just use the latest one pushed
docker run --rm --name "rclone-hdfs" -p 127.0.0.1:9866:9866 -p 127.0.0.1:8020:8020 --hostname "rclone-hdfs" rclone/test-hdfs
NB it need few seconds to startup.
For this docker image the remote needs to be configured like this:
[remote] type = hdfs namenode = 127.0.0.1:8020 username = root
You can stop this image with docker kill rclone-hdfs (NB it does not use volumes, so all data uploaded will be lost.)
Modified time Time accurate to 1 second is stored.
Checksum No checksums are implemented.
Usage information You can use the rclone about remote: command which will display filesystem size and current usage.
Character   Value   Replacement ──────────────────────────────── :           0x3A         ：
Invalid UTF-8 bytes will also be replaced (https://rclone.org/overview/#invalid-utf8).
Standard options Here are the standard options specific to hdfs (Hadoop distributed file system).
--hdfs-namenode Hadoop name node and port.
E.g.  "namenode:8020" to connect to host namenode at port 8020.
• Config: namenode
• Env Var: RCLONE_HDFS_NAMENODE
--hdfs-username Hadoop user name.
• Config: username
• Env Var: RCLONE_HDFS_USERNAME
• "root"
• Connect to hdfs as root.
Advanced options Here are the advanced options specific to hdfs (Hadoop distributed file system).
--hdfs-service-principal-name Kerberos service principal name for the namenode.
Enables KERBEROS authentication.  Specifies the Service Principal Name (SERVICE/FQDN) for the namenode.  E.g.  "hdfs/namenode.hadoop.docker" for namenode running as service 'hdfs' with FQDN 'namenode.hadoop.docker'.
• Config: service_principal_name
• Env Var: RCLONE_HDFS_SERVICE_PRINCIPAL_NAME
--hdfs-data-transfer-protection Kerberos data transfer protection: authentication|integrity|privacy.
Specifies whether or not authentication, data signature integrity checks, and wire encryption is required when communicating the the datanodes. Possible values are 'authentication', 'integrity' and 'privacy'.  Used only with KERBEROS enabled.
• Config: data_transfer_protection
• Env Var: RCLONE_HDFS_DATA_TRANSFER_PROTECTION
• "privacy"
• Ensure authentication, integrity and encryption enabled.
--hdfs-encoding This sets the encoding for the backend.
• Env Var: RCLONE_HDFS_ENCODING
• Default: Slash,Colon,Del,Ctl,InvalidUtf8,Dot
Limitations • No server-side Move or DirMove.
• Checksums not implemented.
The HTTP remote is a read only remote for reading files of a webserver. The webserver should provide file listings which rclone will read and turn into a remote.  This has been tested with common webservers such as Apache/Nginx/Caddy and will likely work with file listings from most web servers.  (If it doesn't then please file an issue, or send a pull request!)
No remotes found - make a new one n) New remote s) Set configuration password q) Quit config n/s/q> n name> remote Type of storage to configure. Choose a number from below, or type in your own value [snip] XX / http Connection \ "http" [snip] Storage> http URL of http host to connect to Choose a number from below, or type in your own value 1 / Connect to example.com \ "https://example.com" url> https://beta.rclone.org Remote config -------------------- [remote] url = https://beta.rclone.org -------------------- y) Yes this is OK e) Edit this remote d) Delete this remote y/e/d> y Current remotes:
Name                 Type ====                 ==== remote               http
Read only This remote is read only - you can't upload files to an HTTP server.
Modified time Most HTTP servers store time accurate to 1 second.
Checksum No checksums are stored.
Usage without a config file Since the http remote only has one config parameter it is easy to use without a config file:
rclone lsd --http-url https://beta.rclone.org :http:
Standard options Here are the standard options specific to http (http Connection).
--http-url URL of http host to connect to.
E.g.  "https://example.com", or "https://user:pass@example.com" to use a username and password.
• Env Var: RCLONE_HTTP_URL
Advanced options Here are the advanced options specific to http (http Connection).
--http-headers Set HTTP headers for all transactions.
Use this to set additional HTTP headers for all transactions.
The input format is comma separated list of key,value pairs.  Standard CSV encoding (https://godoc.org/encoding/csv) may be used.
For example to set a Cookie use 'Cookie,name=value', or '"Cookie","name=value"'.
You can set multiple headers, e.g. '"Cookie","name=value","Authorization","xxx"'.
• Config: headers
• Env Var: RCLONE_HTTP_HEADERS
• Default:
--http-no-slash Set this if the site doesn't end directories with /.
Use this if your target website does not use / on the end of directories.
A / on the end of a path is how rclone normally tells the difference between files and directories.  If this flag is set, then rclone will treat all files with Content-Type: text/html as directories and read URLs from them rather than downloading them.
Note that this may cause rclone to confuse genuine HTML files with directories.
• Config: no_slash
• Env Var: RCLONE_HTTP_NO_SLASH
--http-no-head Don't use HEAD requests to find file sizes in dir listing.
If your site is being very slow to load then you can try this option. Normally rclone does a HEAD request for each potential file in a directory listing to:
• find its size
• check it really exists
• check to see if it is a directory
If you set this option, rclone will not do the HEAD request.  This will mean
• directory listings are much quicker
• rclone won't have the times or sizes of any files
• some files that don't exist may be in the listing
• Env Var: RCLONE_HTTP_NO_HEAD
Limitations rclone about is not supported by the HTTP backend.  Backends without this capability cannot determine free space for an rclone mount or use policy mfs (most free space) as a member of an rclone union remote.
Hubic Paths are specified as remote:path
Paths are specified as remote:container (or remote: for the lsd command.) You may put subdirectories in too, e.g.  remote:container/path/to/dir.
Configuration The initial setup for Hubic involves getting a token from Hubic which you need to do in your browser.  rclone config walks you through it.
n) New remote s) Set configuration password n/s> n name> remote Type of storage to configure. Choose a number from below, or type in your own value [snip] XX / Hubic \ "hubic" [snip] Storage> hubic Hubic Client Id - leave blank normally. client_id> Hubic Client Secret - leave blank normally. client_secret> Remote config Use auto config? * Say Y if not sure * Say N if you are working on a remote or headless machine y) Yes n) No y/n> y If your browser doesn't open automatically go to the following link: http://127.0.0.1:53682/auth Log in and authorize rclone for access Waiting for code... Got code -------------------- [remote] client_id = client_secret = token = {"access_token":"XXXXXX"} -------------------- y) Yes this is OK e) Edit this remote d) Delete this remote y/e/d> y
Note that rclone runs a webserver on your local machine to collect the token as returned from Hubic.  This only runs from the moment it opens your browser to the moment you get back the verification code.  This is on http://127.0.0.1:53682/ and this it may require you to unblock it temporarily if you are running a host firewall.
List containers in the top level of your Hubic
List all the files in your Hubic
To copy a local directory to an Hubic directory called backup
If you want the directory to be visible in the official Hubic browser, you need to copy your files to the default directory
rclone copy /home/source remote:default/backup
Modified time The modified time is stored as metadata on the object as X-Object-Meta-Mtime as floating point since the epoch accurate to 1 ns.
This is a de facto standard (used in the official python-swiftclient amongst others) for storing the modification time for an object.
Note that Hubic wraps the Swift backend, so most of the properties of are the same.
Standard options Here are the standard options specific to hubic (Hubic).
--hubic-client-id OAuth Client Id.
• Env Var: RCLONE_HUBIC_CLIENT_ID
--hubic-client-secret OAuth Client Secret.
• Env Var: RCLONE_HUBIC_CLIENT_SECRET
Advanced options Here are the advanced options specific to hubic (Hubic).
--hubic-token OAuth Access Token as a JSON blob.
• Env Var: RCLONE_HUBIC_TOKEN
--hubic-auth-url Auth server URL.
• Env Var: RCLONE_HUBIC_AUTH_URL
--hubic-token-url Token server url.
• Env Var: RCLONE_HUBIC_TOKEN_URL
--hubic-chunk-size Above this size files will be chunked into a _segments container.
Above this size files will be chunked into a _segments container.  The default for this is 5 GiB which is its maximum value.
• Env Var: RCLONE_HUBIC_CHUNK_SIZE
• Default: 5Gi
--hubic-no-chunk Don't chunk files during streaming upload.
When doing streaming uploads (e.g.  using rcat or mount) setting this flag will cause the swift backend to not upload chunked files.
This will limit the maximum upload size to 5 GiB.  However non chunked files are easier to deal with and have an MD5SUM.
Rclone will still chunk files bigger than chunk_size when doing normal copy operations.
• Config: no_chunk
• Env Var: RCLONE_HUBIC_NO_CHUNK
--hubic-encoding This sets the encoding for the backend.
• Env Var: RCLONE_HUBIC_ENCODING
• Default: Slash,InvalidUtf8
Limitations This uses the normal OpenStack Swift mechanism to refresh the Swift API credentials and ignores the expires field returned by the Hubic API.
The Swift API doesn't return a correct MD5SUM for segmented files (Dynamic or Static Large Objects) so rclone won't check or use the MD5SUM for these.
Jottacloud Jottacloud is a cloud storage service provider from a Norwegian company, using its own datacenters in Norway.  In addition to the official service at jottacloud.com (https://www.jottacloud.com/), it also provides white-label solutions to different companies, such as: * Telia * Telia Cloud (cloud.telia.se) * Telia Sky (sky.telia.no) * Tele2 * Tele2 Cloud (mittcloud.tele2.se) * Elkjøp (with subsidiaries): * Elkjøp Cloud (cloud.elkjop.no) * Elgiganten Sweden (cloud.elgiganten.se) * Elgiganten Denmark (cloud.elgiganten.dk) * Giganti Cloud (cloud.gigantti.fi) * ELKO Clouud (cloud.elko.is)
Most of the white-label versions are supported by this backend, although may require different authentication setup - described below.
Authentication types Some of the whitelabel versions uses a different authentication method than the official service, and you have to choose the correct one when setting up the remote.
Standard authentication To configure Jottacloud you will need to generate a personal security token in the Jottacloud web interface.  You will the option to do in your account security settings (https://www.jottacloud.com/web/secure) (for whitelabel version you need to find this page in its web interface). Note that the web interface may refer to this token as a JottaCli token.
Legacy authentication If you are using one of the whitelabel versions (e.g.  from Elkjøp or Tele2) you may not have the option to generate a CLI token.  In this case you'll have to use the legacy authentication.  To to this select yes when the setup asks for legacy authentication and enter your username and password.  The rest of the setup is identical to the default setup.
Telia Cloud authentication Similar to other whitelabel versions Telia Cloud doesn't offer the option of creating a CLI token, and additionally uses a separate authentication flow where the username is generated internally.  To setup rclone to use Telia Cloud, choose Telia Cloud authentication in the setup.  The rest of the setup is identical to the default setup.
Configuration Here is an example of how to make a remote called remote with the default setup.  First run:
No remotes found - make a new one n) New remote s) Set configuration password q) Quit config n/s/q> n name> remote Type of storage to configure. Enter a string value. Press Enter for the default (""). Choose a number from below, or type in your own value [snip] XX / Jottacloud \ "jottacloud" [snip] Storage> jottacloud ** See help for jottacloud backend at: https://rclone.org/jottacloud/ **
Edit advanced config? (y/n) y) Yes n) No y/n> n Remote config Use legacy authentication?. This is only required for certain whitelabel versions of Jottacloud and not recommended for normal users. y) Yes n) No (default) y/n> n
Generate a personal login token here: https://www.jottacloud.com/web/secure Login Token> <your token here>
Do you want to use a non standard device/mountpoint e.g. for accessing files uploaded using the official Jottacloud client?
y) Yes n) No y/n> y Please select the device to use. Normally this will be Jotta Choose a number from below, or type in an existing value 1 > DESKTOP-3H31129 2 > Jotta Devices> 2 Please select the mountpoint to user. Normally this will be Archive Choose a number from below, or type in an existing value 1 > Archive 2 > Links 3 > Sync
Mountpoints> 1 -------------------- [jotta] type = jottacloud token = {........} device = Jotta mountpoint = Archive configVersion = 1 -------------------- y) Yes this is OK e) Edit this remote d) Delete this remote y/e/d> y
List directories in top level of your Jottacloud
List all the files in your Jottacloud
To copy a local directory to an Jottacloud directory called backup
Devices and Mountpoints The official Jottacloud client registers a device for each computer you install it on, and then creates a mountpoint for each folder you select for Backup.  The web interface uses a special device called Jotta for the Archive and Sync mountpoints.  In most cases you'll want to use the Jotta/Archive device/mountpoint, however if you want to access files uploaded by any of the official clients rclone provides the option to select other devices and mountpoints during config.
The built-in Jotta device may also contain several other mountpoints, such as: Latest, Links, Shared and Trash.  These are special mountpoints with a different internal representation than the "regular" mountpoints. Rclone will only to a very limited degree support them.  Generally you should avoid these, unless you know what you are doing.
Note that the implementation in Jottacloud always uses only a single API request to get the entire list, so for large folders this could lead to long wait time before the first results are shown.
Modified time and hashes Jottacloud allows modification times to be set on objects accurate to 1 second.  These will be used to detect whether objects need syncing or not.
Jottacloud supports MD5 type hashes, so you can use the --checksum flag.
Note that Jottacloud requires the MD5 hash before upload so if the source does not have an MD5 checksum then the file will be cached temporarily on disk (wherever the TMPDIR environment variable points to) before it is uploaded.  Small files will be cached in memory - see the --jottacloud-md5-memory-limit flag.  When uploading from local disk the source checksum is always available, so this does not apply.  Starting with rclone version 1.52 the same is true for crypted remotes (in older versions the crypt backend would not calculate hashes for uploads from local disk, so the Jottacloud backend had to do it as described above).
Character   Value   Replacement ──────────────────────────────── "           0x22         ＂ *           0x2A         ＊ :           0x3A         ： <           0x3C         ＜ >           0x3E         ＞ ?           0x3F         ？ |           0x7C         ｜
Invalid UTF-8 bytes will also be replaced (https://rclone.org/overview/#invalid-utf8), as they can't be used in XML strings.
Deleting files By default rclone will send all files to the trash when deleting files. They will be permanently deleted automatically after 30 days.  You may bypass the trash and permanently delete files immediately by using the --jottacloud-hard-delete flag, or set the equivalent environment variable.  Emptying the trash is supported by the cleanup (https://rclone.org/commands/rclone_cleanup/) command.
Versions Jottacloud supports file versioning.  When rclone uploads a new version of a file it creates a new version of it.  Currently rclone only supports retrieving the current version but older versions can be accessed via the Jottacloud Website.
Versioning can be disabled by --jottacloud-no-versions option.  This is achieved by deleting the remote file prior to uploading a new version. If the upload the fails no version of the file will be available in the remote.
Quota information To view your current quota you can use the rclone about remote: command which will display your usage limit (unless it is unlimited) and the current usage.
Advanced options Here are the advanced options specific to jottacloud (Jottacloud).
--jottacloud-md5-memory-limit Files bigger than this will be cached on disk to calculate the MD5 if required.
• Config: md5_memory_limit
• Env Var: RCLONE_JOTTACLOUD_MD5_MEMORY_LIMIT
• Default: 10Mi
--jottacloud-trashed-only Only show files that are in the trash.
• Env Var: RCLONE_JOTTACLOUD_TRASHED_ONLY
--jottacloud-hard-delete Delete files permanently rather than putting them into the trash.
• Env Var: RCLONE_JOTTACLOUD_HARD_DELETE
--jottacloud-upload-resume-limit Files bigger than this can be resumed if the upload fail's.
• Config: upload_resume_limit
• Env Var: RCLONE_JOTTACLOUD_UPLOAD_RESUME_LIMIT
--jottacloud-no-versions Avoid server side versioning by deleting files and recreating files instead of overwriting them.
• Config: no_versions
• Env Var: RCLONE_JOTTACLOUD_NO_VERSIONS
--jottacloud-encoding This sets the encoding for the backend.
• Env Var: RCLONE_JOTTACLOUD_ENCODING
• Default: Slash,LtGt,DoubleQuote,Colon,Question,Asterisk,Pipe,Del,Ctl,InvalidUtf8,Dot
Limitations Note that Jottacloud is case insensitive so you can't have a file called "Hello.doc" and one called "hello.doc".
There are quite a few characters that can't be in Jottacloud file names. Rclone will map these names to and from an identical looking unicode equivalent.  For example if a file has a ?  in it will be mapped to ？ instead.
Jottacloud only supports filenames up to 255 characters in length.
Troubleshooting Jottacloud exhibits some inconsistent behaviours regarding deleted files and folders which may cause Copy, Move and DirMove operations to previously deleted paths to fail.  Emptying the trash should help in such cases.
Koofr Paths are specified as remote:path
Configuration The initial setup for Koofr involves creating an application password for rclone.  You can do that by opening the Koofr web application (https://app.koofr.net/app/admin/preferences/password), giving the password a nice name like rclone and clicking on generate.
Here is an example of how to make a remote called koofr.  First run:
No remotes found - make a new one n) New remote s) Set configuration password q) Quit config n/s/q> n name> koofr Type of storage to configure. Enter a string value. Press Enter for the default (""). Choose a number from below, or type in your own value [snip] XX / Koofr \ "koofr" [snip] Storage> koofr ** See help for koofr backend at: https://rclone.org/koofr/ **
Your Koofr user name Enter a string value. Press Enter for the default (""). user> USER@NAME Your Koofr password for rclone (generate one at https://app.koofr.net/app/admin/preferences/password) y) Yes type in my own password g) Generate random password y/g> y Enter the password: password: Confirm the password: password: Edit advanced config? (y/n) y) Yes n) No y/n> n Remote config -------------------- [koofr] type = koofr baseurl = https://app.koofr.net user = USER@NAME password = *** ENCRYPTED *** -------------------- y) Yes this is OK e) Edit this remote d) Delete this remote y/e/d> y
You can choose to edit advanced config in order to enter your own service URL if you use an on-premise or white label Koofr instance, or choose an alternative mount instead of your primary storage.
List directories in top level of your Koofr
rclone lsd koofr:
List all the files in your Koofr
rclone ls koofr:
To copy a local directory to an Koofr directory called backup
Standard options Here are the standard options specific to koofr (Koofr).
--koofr-user Your Koofr user name.
• Env Var: RCLONE_KOOFR_USER
--koofr-password Your Koofr password for rclone (generate one at https://app.koofr.net/app/admin/preferences/password).
• Env Var: RCLONE_KOOFR_PASSWORD
Advanced options Here are the advanced options specific to koofr (Koofr).
--koofr-endpoint The Koofr API endpoint to use.
• Env Var: RCLONE_KOOFR_ENDPOINT
• Default: "https://app.koofr.net"
--koofr-mountid Mount ID of the mount to use.
If omitted, the primary mount is used.
• Config: mountid
• Env Var: RCLONE_KOOFR_MOUNTID
--koofr-setmtime Does the backend support setting modification time.
Set this to false if you use a mount ID that points to a Dropbox or Amazon Drive backend.
• Config: setmtime
• Env Var: RCLONE_KOOFR_SETMTIME
--koofr-encoding This sets the encoding for the backend.
• Env Var: RCLONE_KOOFR_ENCODING
Limitations Note that Koofr is case insensitive so you can't have a file called "Hello.doc" and one called "hello.doc".
Mail.ru Cloud Mail.ru Cloud (https://cloud.mail.ru/) is a cloud storage provided by a Russian internet company Mail.Ru Group (https://mail.ru).  The official desktop client is Disk-O: (https://disk-o.cloud/en), available on Windows and Mac OS.
Currently it is recommended to disable 2FA on Mail.ru accounts intended for rclone until it gets eventually implemented.
Features highlights • Paths may be as deep as required, e.g.  remote:directory/subdirectory
• Files have a last modified time property, directories don't
• Deleted files are by default moved to the trash
• Files and directories can be shared via public links
• Partial uploads or streaming are not supported, file size must be known before upload
• Maximum file size is limited to 2G for a free account, unlimited for paid accounts
• Storage keeps hash for all files and performs transparent deduplication, the hash algorithm is a modified SHA1
• If a particular file is already present in storage, one can quickly submit file hash instead of long file upload (this optimization is supported by rclone)
Configuration Here is an example of making a mailru configuration.  First create a Mail.ru Cloud account and choose a tariff, then run
No remotes found - make a new one n) New remote s) Set configuration password q) Quit config n/s/q> n name> remote Type of storage to configure. Type of storage to configure. Enter a string value. Press Enter for the default (""). Choose a number from below, or type in your own value [snip] XX / Mail.ru Cloud \ "mailru" [snip] Storage> mailru User name (usually email) Enter a string value. Press Enter for the default (""). user> username@mail.ru Password y) Yes type in my own password g) Generate random password y/g> y Enter the password: password: Confirm the password: password: Skip full upload if there is another file with same data hash. This feature is called "speedup" or "put by hash". It is especially efficient in case of generally available files like popular books, video or audio clips [snip] Enter a boolean value (true or false). Press Enter for the default ("true"). Choose a number from below, or type in your own value 1 / Enable \ "true" 2 / Disable \ "false" speedup_enable> 1 Edit advanced config? (y/n) y) Yes n) No y/n> n Remote config -------------------- [remote] type = mailru user = username@mail.ru pass = *** ENCRYPTED *** speedup_enable = true -------------------- y) Yes this is OK e) Edit this remote d) Delete this remote y/e/d> y
Configuration of this backend does not require a local web browser.  You can use the configured backend as shown below:
See top level directories
rclone mkdir remote:directory
Sync /home/local/directory to the remote path, deleting any excess files in the path.
Modified time Files support a modification time attribute with up to 1 second precision.  Directories do not have a modification time, which is shown as "Jan 1 1970".
Hash checksums Hash sums use a custom Mail.ru algorithm based on SHA1.  If file size is less than or equal to the SHA1 block size (20 bytes), its hash is simply its data right-padded with zero bytes.  Hash sum of a larger file is computed as a SHA1 sum of the file data bytes concatenated with a decimal representation of the data length.
Emptying Trash Removing a file or directory actually moves it to the trash, which is not visible to rclone but can be seen in a web browser.  The trashed file still occupies part of total quota.  If you wish to empty your trash and free some quota, you can use the rclone cleanup remote: command, which will permanently delete all your trashed files.  This command does not take any path arguments.
Quota information To view your current quota you can use the rclone about remote: command which will display your usage limit (quota) and the current usage.
Character   Value   Replacement ──────────────────────────────── "           0x22         ＂ *           0x2A         ＊ :           0x3A         ： <           0x3C         ＜ >           0x3E         ＞ ?           0x3F         ？ \           0x5C         ＼ |           0x7C         ｜
Standard options Here are the standard options specific to mailru (Mail.ru Cloud).
--mailru-user User name (usually email).
• Env Var: RCLONE_MAILRU_USER
--mailru-pass Password.
• Env Var: RCLONE_MAILRU_PASS
--mailru-speedup-enable Skip full upload if there is another file with same data hash.
This feature is called "speedup" or "put by hash".  It is especially efficient in case of generally available files like popular books, video or audio clips, because files are searched by hash in all accounts of all mailru users.  It is meaningless and ineffective if source file is unique or encrypted.  Please note that rclone may need local memory and disk space to calculate content hash in advance and decide whether full upload is required.  Also, if rclone does not know file size in advance (e.g. in case of streaming or partial uploads), it will not even try this optimization.
• Config: speedup_enable
• Env Var: RCLONE_MAILRU_SPEEDUP_ENABLE
• Enable
• Disable
Advanced options Here are the advanced options specific to mailru (Mail.ru Cloud).
--mailru-speedup-file-patterns Comma separated list of file name patterns eligible for speedup (put by hash).
Patterns are case insensitive and can contain '*' or '?' meta characters.
• Config: speedup_file_patterns
• Env Var: RCLONE_MAILRU_SPEEDUP_FILE_PATTERNS
• Default: ".mkv,.avi,.mp4,.mp3,.zip,.gz,.rar,.pdf"
• Empty list completely disables speedup (put by hash).
• "*"
• All files will be attempted for speedup.
• ".mkv,.avi,.mp4,.mp3"
• Only common audio/video files will be tried for put by hash.
• ".zip,.gz,.rar,.pdf"
• Only common archives or PDF books will be tried for speedup.
--mailru-speedup-max-disk This option allows you to disable speedup (put by hash) for large files.
Reason is that preliminary hashing can exhaust your RAM or disk space.
• Config: speedup_max_disk
• Env Var: RCLONE_MAILRU_SPEEDUP_MAX_DISK
• Default: 3Gi
• "0"
• Completely disable speedup (put by hash).
• Files larger than 1Gb will be uploaded directly.
• "3G"
• Choose this option if you have less than 3Gb free on local disk.
--mailru-speedup-max-memory Files larger than the size given below will always be hashed on disk.
• Config: speedup_max_memory
• Env Var: RCLONE_MAILRU_SPEEDUP_MAX_MEMORY
• Default: 32Mi
• Preliminary hashing will always be done in a temporary disk location.
• "32M"
• Do not dedicate more than 32Mb RAM for preliminary hashing.
• "256M"
• You have at most 256Mb RAM free for hash calculations.
--mailru-check-hash What should copy do if file checksum is mismatched or invalid.
• Config: check_hash
• Env Var: RCLONE_MAILRU_CHECK_HASH
• Fail with error.
• Ignore and continue.
--mailru-user-agent HTTP user agent used internally by client.
Defaults to "rclone/VERSION" or "--user-agent" provided on command line.
• Config: user_agent
• Env Var: RCLONE_MAILRU_USER_AGENT
--mailru-quirks Comma separated list of internal maintenance flags.
This option must not be used by an ordinary user.  It is intended only to facilitate remote troubleshooting of backend issues.  Strict meaning of flags is not documented and not guaranteed to persist between releases. Quirks will be removed when the backend grows stable.  Supported quirks: atomicmkdir binlist unknowndirs
• Config: quirks
• Env Var: RCLONE_MAILRU_QUIRKS
--mailru-encoding This sets the encoding for the backend.
• Env Var: RCLONE_MAILRU_ENCODING
• Default: Slash,LtGt,DoubleQuote,Colon,Question,Asterisk,Pipe,BackSlash,Del,Ctl,InvalidUtf8,Dot
Limitations File size limits depend on your account.  A single file size is limited by 2G for a free account and unlimited for paid tariffs.  Please refer to the Mail.ru site for the total uploaded size limits.
Note that Mailru is case insensitive so you can't have a file called "Hello.doc" and one called "hello.doc".
Mega Mega (https://mega.nz/) is a cloud storage and file hosting service known for its security feature where all files are encrypted locally before they are uploaded.  This prevents anyone (including employees of Mega) from accessing the files without knowledge of the key used for encryption.
This is an rclone backend for Mega which supports the file transfer features of Mega using the same client side encryption.
No remotes found - make a new one n) New remote s) Set configuration password q) Quit config n/s/q> n name> remote Type of storage to configure. Choose a number from below, or type in your own value [snip] XX / Mega \ "mega" [snip] Storage> mega User name user> you@example.com Password. y) Yes type in my own password g) Generate random password n) No leave this optional password blank y/g/n> y Enter the password: password: Confirm the password: password: Remote config -------------------- [remote] type = mega user = you@example.com pass = *** ENCRYPTED *** -------------------- y) Yes this is OK e) Edit this remote d) Delete this remote y/e/d> y
NOTE: The encryption keys need to have been already generated after a regular login via the browser, otherwise attempting to use the credentials in rclone will fail.
List directories in top level of your Mega
List all the files in your Mega
To copy a local directory to an Mega directory called backup
Modified time and hashes Mega does not support modification times or hashes yet.
Duplicated files Mega can have two files with exactly the same name and path (unlike a normal file system).
Failure to log-in Mega remotes seem to get blocked (reject logins) under "heavy use".  We haven't worked out the exact blocking rules but it seems to be related to fast paced, successive rclone commands.
For example, executing this command 90 times in a row rclone link remote:file will cause the remote to become "blocked".  This is not an abnormal situation, for example if you wish to get the public links of a directory with hundred of files...  After more or less a week, the remote will remote accept rclone logins normally again.
You can mitigate this issue by mounting the remote it with rclone mount. This will log-in when mounting and a log-out when unmounting only.  You can also run rclone rcd and then use rclone rc to run the commands over the API to avoid logging in each time.
Rclone does not currently close mega sessions (you can see them in the web interface), however closing the sessions does not solve the issue.
If you space rclone commands by 3 seconds it will avoid blocking the remote.  We haven't identified the exact blocking rules, so perhaps one could execute the command 80 times without waiting and avoid blocking by waiting 3 seconds, then continuing...
Note that this has been observed by trial and error and might not be set in stone.
Other tools seem not to produce this blocking effect, as they use a different working approach (state-based, using sessionIDs instead of log-in) which isn't compatible with the current stateless rclone approach.