Skip to content

Add cloud service account

A cloud service account can be added by providing login credentials for FolderSync to be able to login and access fils. Some cloud services support OAuth authentication where you login on the cloud provider website. In those cases FolderSync will not have access to or store your login credentials, but are granted an access token that can be revoked later.

Cloud providers using OAuth authentication

For cloud services like Box, Dropbox, Google Drive, Hubic, OneDrive, Yandex and pCloud you can initiate the browser based authentication flow by pressing Authenticate Account button. After you have authenticated in the browser it should redirect you back to the app and you see that the account has been authenticated.

If you are instead redirected back to a webpage, you can copy the fallback OAuth code, press back until you see the account screen in FolderSync again and use the Enter OAuth code button to enter the code.

Issue with pCloud and EU server

For pCloud access the manual fallback method will not work when using EU server.

Example - Google Drive

In this example press the Authenticate account button to initiate authentication in a browser. When done, you should be returned to FolderSync and see second screen. You're account should now be ready to use.

Screenshot Screenshot

Cloud providers using login credentials

For login based cloud providers like CloudMe, HiDrive, Livedrive, MEGA,,, NetDocuments, Storegate, SugarSync etc. you will need to enter your credentials to the service to be able connect. This login information will be stored in the FolderSync database, so ensure to encrypt any backup you make of the FolderSync database.

Amazon S3 protocol

When connecting to server using the S3 protocol you have 3 options, depending on the type of S3 server you are connecting to. We will go through the configuration option for these below.

Amazon S3

Used this for connection to Amazon S3 standard or using custom endpoints.

  • Access key ID: The access key ID.
  • Secret access key: The secret access key.
  • Custom endpoint: If targeting custom S3 endpoint enter it here.
  • Server-side encryption: Check if you want to use Amazon SSE.
  • Use reduced redundancy: If you want to use reduced redundancy for buckets created.
  • Region: The region with which to use this account entry.

Regarding region setting

Amazon region is only used in regards to creating a bucket in this application - all other operations are targeted to a specific bucket you specify, no matter with which region endpoint it was created. Using Amazon S3 can incur costs on your part.

S3 Compatible

Use this for connecting to S3 compatible services such as Backblaze, Filebase and STORJ. The official Amazon S3 Java SDK is used.

  • Access key ID: The access key ID.
  • Secret access key: The secret access key.
  • Server address: The S3 server address as defined by the cloud service.
  • Use path-style access: Some S3 compatible services require this to be checked.
  • Region: Some S3 compatible services may use the region parameter.


A MinIO account can be used to target S3-compatible servers other than MinIO. The MinIO Java SDK is used.

  • Access key ID: The access key ID.
  • Secret access key: The secret access key.
  • Server address: The IP address or hostname of the MinIO server (without protocol or path), so like “” or “”.
  • Port: The port to use.
  • Allow self-signed cert: If you want to allow connections to server using a self-signed root certificate for HTTPS.
  • Region: Some MinIO servers may use the region parameter.

Allowing self-signed certificates

For security reasons this should not be enabled for servers unless you know what you are doing. If a server owner uses a self-signed certificate to provide HTTPS services, FolderSync cannot be certain that it is connected to the intended destination. For all FolderSync knows, malicious third-party could be redirecting the connection using another self-signed certificate bearing the same holder name. The connection is still encrypted, but does not lead to its intended target. In comparison, a CA-signed certificate prevents this attack because the app separately validates the certificate against the issuing CA. The attacker's certificate fails this validation.