Issue connecting with pCloud on specific device

What is the problem you are having with rclone?

Only on one specific device (an Odroid C2 SBC running Alpine Linux in a Docker container) am I having an issue connecting with pcloud. I can successfully authenticate and receive a token, but when I try to list directories, I get an error. I do not have this issue when running rclone on Windows natively, and even copying the configuration file from the Windows machine to the Odroid C2/container results in the same error on the Odroid C2.

Run the command 'rclone version' and share the full output of the command.

rclone v1.69.1
- os/version: alpine 3.21.2 (64 bit)
- os/kernel: 3.16.85-65 (aarch64)
- os/type: linux
- os/arch: arm64 (ARMv8 compatible)
- go/version: go1.24.0
- go/linking: static
- go/tags: none

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

pCloud

The command you were trying to run (eg rclone copy /tmp remote:tmp)

rclone lsd pcloud: -vv

Please run 'rclone config redacted' and share the full output. If you get command not found, please make sure to update rclone.

[pcloud]
type = pcloud
client_id = XXX
client_secret = XXX
hostname = api.pcloud.com
token = XXX

A log from the command that you were trying to run with the -vv flag

2025/04/21 22:52:31 DEBUG : Setting --user "admin" from environment variable RCLONE_USER="admin"
2025/04/21 22:52:31 DEBUG : Setting --pass "XXX" from environment variable RCLONE_PASS="XXX"
2025/04/21 22:52:31 DEBUG : Setting --user "admin" from environment variable RCLONE_USER="admin"
2025/04/21 22:52:31 DEBUG : Setting --pass "XXX" from environment variable RCLONE_PASS="XXX"
2025/04/21 22:52:31 DEBUG : Setting --user "admin" from environment variable RCLONE_USER="admin"
2025/04/21 22:52:31 DEBUG : Setting --pass "XXX" from environment variable RCLONE_PASS="XXX"
2025/04/21 22:52:31 DEBUG : Setting --user "admin" from environment variable RCLONE_USER="admin"
2025/04/21 22:52:31 DEBUG : Setting --pass "XXX" from environment variable RCLONE_PASS="XXX"
2025/04/21 22:52:31 DEBUG : Setting --user "admin" from environment variable RCLONE_USER="admin"
2025/04/21 22:52:31 DEBUG : Setting --pass "XXX" from environment variable RCLONE_PASS="XXX"
2025/04/21 22:52:31 DEBUG : Setting  user="admin" from environment variable RCLONE_USER
2025/04/21 22:52:31 DEBUG : Setting  pass="XXX" from environment variable RCLONE_PASS
2025/04/21 22:52:31 DEBUG : Setting --user "admin" from environment variable RCLONE_USER="admin"
2025/04/21 22:52:31 DEBUG : Setting --pass "XXX" from environment variable RCLONE_PASS="XXX"
2025/04/21 22:52:31 DEBUG : Setting --user "admin" from environment variable RCLONE_USER="admin"
2025/04/21 22:52:31 DEBUG : Setting --pass "XXX" from environment variable RCLONE_PASS="XXX"
2025/04/21 22:52:31 DEBUG : Setting --pcloud-client-id "XXX" from environment variable RCLONE_PCLOUD_CLIENT_ID="XXX"
2025/04/21 22:52:31 DEBUG : Setting --pcloud-client-secret "XXX" from environment variable RCLONE_PCLOUD_CLIENT_SECRET="XXX"
2025/04/21 22:52:31 DEBUG : Setting --pcloud-token "XXX" from environment variable RCLONE_PCLOUD_TOKEN="XXX"
2025/04/21 22:52:31 DEBUG : rclone: Version "v1.69.1" starting with parameters ["rclone" "lsd" "pcloud:" "-vv"]
2025/04/21 22:52:31 DEBUG : Creating backend with remote "pcloud:"
2025/04/21 22:52:31 DEBUG : Using config file from "/config/rclone/rclone.conf"
2025/04/21 22:52:31 DEBUG : pcloud: detected overridden config - adding "{w_tt-}" suffix to name
2025/04/21 22:52:31 CRITICAL: Failed to create file system for "pcloud:": failed to configure Pcloud: invalid character 'h' after top-level value

welcome to the forum,

what is that about?

could be a corrupted rclone config file.

most cross platform issues are about syntax and line endings.

please post a complete debug log, not snippets

That comes from my docker compose file:

services:
  rclone:
    image: rclone/rclone:latest
    container_name: rclone
    ports:
      - 5772:5772  # rclone API exposed to other containers
    volumes:
      - /opt/docker-apps/rclone/config:/config/rclone  # Map rclone config
      - /opt/docker-apps/rclone/data:/data
      - /opt/docker-apps/rclone/cache:/root/.cache/rclone
      - /opt/docker-apps/rclone/logs:/logs
    env_file:
      - ./stack.env
    command:
      - rcd
      - --rc-web-gui
      - --rc-web-gui-no-open-browser
      - --rc-addr=:5772
      - --rc-user=${RCLONE_USER}
      - --rc-pass=${RCLONE_PASS}
      - --log-file=/logs/rclone.log
      - --log-level=NOTICE
      - --cache-dir=/vfsCache
    cap_add:
      - SYS_ADMIN
    devices:
      - /dev/fuse:/dev/fuse:rwm
    security_opt:
      - apparmor:unconfined
    environment:
      - TZ=America/New_York
      - PUID=1000
      - PGID=1000
    networks:
      - rclone-net
    restart: always

networks:
  rclone-net:
    driver: bridge

When i create the config file fresh on the C2, i get this error. When i create it on my windows device, test it, and transfer it over, i get the same error. I do not have the issue when transferring from the C2 to the Windows device.

That is the full debug log, with only the Password, Client Secret, and token redacted.

i would do a binary diff between the windows config and linux config

also, on linux, post rclone config show pcloud: with symbols displayed
to redact, change just one letter in the middle of each line item.

[pcloud]
type = pcloud
client_id = 2utnARjYmjf
client_secret = 5wt8fgfOm9f7HoARNwtt6u97DGMk
hostname = api.pcloud.com
token = {"access_token":"7hDCZ2utnLHjYmjfZU6p7VkZ5IArkAA35i53S556G8teGYONeBXX","token_type":"bearer","expiry":"0001-01-01T00:00:00Z"}

Quick update for this thread: To help distribute my containers and as a troubleshooting step, I acquired a second device identical to the one having trouble with rclone and pcloud.

I configured rclone on this new device using the exact same configuration file as the problematic one, and it's working without any issues.

This is quite puzzling, as I've already gone through extensive troubleshooting on the original machine, including uninstalling and deleting rclone files, and removing and recreating containers and volumes. Despite these efforts, the problem remains on that specific device
Having this side-by-side comparison with an identical, working setup reinforces that the issue is localized to the original machine. Hopefully, this information is useful in diagnosing the root cause

1 Like