Recursive pcloud root failure

What is the problem you are having with rclone?

lsjson recurse in pcloud root fails

This happens since today, 3 April 2026. Yesterday at 4:19 AM Romanian timezone was fine with same rclone v1.73.3. I’m pretty sure something on pcloud side changed meanwhile.

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

rclone v1.73.3

  • os/version: ubuntu 25.04 (64 bit)
  • os/kernel: 6.14.0-37-generic (x86_64)
  • os/type: linux
  • os/arch: amd64
  • go/version: go1.25.8
  • 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 lsjson pcloud7: --no-mimetype --fast-list --recursive

The rclone config contents with secrets removed.

[pcloud7]
type = pcloud
hostname = eapi.pcloud.com
token = ...
username = ...@gmail.com
password = ...

A log from the command with the -vv flag

# no recursive root access is ok
rclone lsjson pcloud7: --no-mimetype --fast-list
[{"Path":"fast-disk","Name":"fast-disk","Size":-1,"ModTime":"2026-01-05T01:16:30Z","IsDir":true,"ID":"d17158715970"},
{"Path":"home","Name":"home","Size":-1,"ModTime":"2025-05-30T03:06:43Z","IsDir":true,"ID":"d12409967435"},
{"Path":"mnt","Name":"mnt","Size":-1,"ModTime":"2025-05-30T03:12:40Z","IsDir":true,"ID":"d17158774289"},
{"Path":"var","Name":"var","Size":-1,"ModTime":"2026-02-15T01:15:05Z","IsDir":true,"ID":"d22398713924"}]

# recurse in directory is ok
rclone lsjson pcloud7:var --no-mimetype --fast-list --recursive     
[
{"Path":"lib","Name":"lib","Size":-1,"ModTime":"2026-02-15T01:15:05Z","IsDir":true,"ID":"d22398713975"}
]

# recurse in root fails
rclone lsjson pcloud7: --no-mimetype --fast-list --recursive -vvv
2026/04/03 10:26:47 DEBUG : rclone: Version "v1.73.3" starting with parameters ["rclone" "lsjson" "pcloud7:" "--no-mimetype" "--fast-list" "--recursive" "-vvv"]
2026/04/03 10:26:47 DEBUG : Creating backend with remote "pcloud7:"
2026/04/03 10:26:47 DEBUG : Using config file from "/home/adr/.config/rclone/rclone.conf"
[
2026/04/03 10:26:47 DEBUG : 5 go routines active
2026/04/03 10:26:47 NOTICE: Failed to lsjson: error in ListJSON: couldn't list files: pcloud error: Invalid request. (1101)

Shouldn’t you then report it to pcloud? They can fix it or let you know what has changed - if some action is required on rclone end we can take it from there.

pCloud doesn’t support rclone.

rclone’s purpose is to offer a common interface to various cloud providers, it’s not a standard or commonly-accepted protocol of accessing cloud services. That’s why pCloud won’t bother to accommodate rclone, it’s rclone that has to change to continue to support pCloud, if it’s team desire to do so.

Imagine that one day Google changes something to Google Drive and rclone is no longer able to work with it. That’s rclone’s problem but not Google’s (or pCloud’s, in the current case).

According to pCloud and rclone lsjson the problem I found is a bug (aka, a feature no longer working as claimed).

PS: the rclone beta version tested 6 hours ago has the same issue (this is not surprising)

welcome to the forum,

that is not a bug, rclone is working as it was designed.

i think i should change this topic from bug to help and support
the issue is with pcloud, either changing their api or some temporary server issue.
nothing to do with rclone.


how do you know this is not a bug with pcloud?


for a deeper look at the api calls, use --dump=headers


those are just links to rclone's documentation.
there is no information at all about bugs or pcloud api changes??


contact pcloud, do not mention rclone.
simply ask if there is a server issue or a recent change to api calls

According to the rclone documentation (the 2 links posted before) this command should work:

rclone lsjson pcloud7: --no-mimetype --fast-list --recursive -vv

but it doesn’t.

On the other hand these do work:

rclone lsjson pcloud7:subdir --no-mimetype --fast-list --recursive -vv
rclone lsjson pcloud7: --no-mimetype --fast-list -vv

so there’s no temporary server issue.

pCloud doesn’t support rclone, so pCloud is expected to change its API, or any other aspect of its activity, without notifying rclone. When this happens, and it does happen from time to time with any storage system, rclone has to align itself to pCloud (Google Drive, OneDrive, etc), if it still wants to support pCloud, but not the other way around.

The same applies to the all other storage systems and rclone continuously updates itself to be able to work with them. People like me point out the breaking changes and rclone developers update the software according to their intention (e.g., still support pCloud or not).

Why it makes no sense & use to report this to pCloud:
because pCloud is not supporting rclone (aka, pCloud doesn’t care whether rclone can or not work with it).

thanks for reporting,
i changed the category from bug to help and support


try a simpler command, post the full debug log, not snippets.
rclone ls pcloud7: --recursive -vv

$rclone lsjson pcloud7: --recursive -vv
2026/04/03 22:06:56 DEBUG : rclone: Version "v1.73.3" starting with parameters ["rclone" "lsjson" "pcloud7:" "--recursive" "-vv"]
2026/04/03 22:06:56 DEBUG : Creating backend with remote "pcloud7:"
2026/04/03 22:06:56 DEBUG : Using config file from "/home/gigi/.config/rclone/rclone.conf"
[
2026/04/03 22:06:57 DEBUG : 5 go routines active
2026/04/03 22:06:57 NOTICE: Failed to lsjson: error in ListJSON: couldn't list files: pcloud error: Invalid request. (1101)

$rclone ls pcloud7: --recursive -vv
Error: unknown flag: --recursive
Usage:
  rclone ls remote:path [flags]

Flags:
  -h, --help   help for ls

Flags for filtering directory listings (flag group Filter):
      --delete-excluded                     Delete files on dest excluded from sync
      --exclude stringArray                 Exclude files matching pattern
      --exclude-from stringArray            Read file exclude patterns from file (use - to read from stdin)
      --exclude-if-present stringArray      Exclude directories if filename is present
      --files-from stringArray              Read list of source-file names from file (use - to read from stdin)
      --files-from-raw stringArray          Read list of source-file names from file without any processing of lines (use - to read from stdin)
  -f, --filter stringArray                  Add a file filtering rule
      --filter-from stringArray             Read file filtering patterns from a file (use - to read from stdin)
      --hash-filter string                  Partition filenames by hash k/n or randomly @/n
      --ignore-case                         Ignore case in filters (case insensitive)
      --include stringArray                 Include files matching pattern
      --include-from stringArray            Read file include patterns from file (use - to read from stdin)
      --max-age Duration                    Only transfer files younger than this in s or suffix ms|s|m|h|d|w|M|y (default off)
      --max-depth int                       If set limits the recursion depth to this (default -1)
      --max-size SizeSuffix                 Only transfer files smaller than this in KiB or suffix B|K|M|G|T|P (default off)
      --metadata-exclude stringArray        Exclude metadatas matching pattern
      --metadata-exclude-from stringArray   Read metadata exclude patterns from file (use - to read from stdin)
      --metadata-filter stringArray         Add a metadata filtering rule
      --metadata-filter-from stringArray    Read metadata filtering patterns from a file (use - to read from stdin)
      --metadata-include stringArray        Include metadatas matching pattern
      --metadata-include-from stringArray   Read metadata include patterns from file (use - to read from stdin)
      --min-age Duration                    Only transfer files older than this in s or suffix ms|s|m|h|d|w|M|y (default off)
      --min-size SizeSuffix                 Only transfer files bigger than this in KiB or suffix B|K|M|G|T|P (default off)

Flags for listing directories (flag group Listing):
      --default-time Time   Time to show if modtime is unknown for files and directories (default 2000-01-01T00:00:00Z)
      --fast-list           Use recursive list if available; uses more memory but fewer transactions

Use "rclone [command] --help" for more information about a command.
Use "rclone help flags" for to see the global flags.
Use "rclone help backends" for a list of supported services.

2026/04/03 22:06:41 NOTICE: Fatal error: unknown flag: --recursive

The log I initially posted is the entire log, but not a snippet.

A software engineer has everything necessary to understand the issue.

Because you, @asdffdsa, asked for the logs of `rclone ls pcloud7: --recursive -vv`, though an incorrect command, I let it there.

my bad, as rclone ls is recursive by default.


not yet, please post a complete debug log using --dump=headers

rclone lsjson pcloud7: --recursive --dump=headers -vv
2026/04/03 22:16:30 NOTICE: Automatically setting -vv as --dump is enabled
2026/04/03 22:16:30 DEBUG : rclone: Version "v1.73.3" starting with parameters ["rclone" "lsjson" "pcloud7:" "--recursive" "--dump=headers" "-vv"]
2026/04/03 22:16:30 DEBUG : Creating backend with remote "pcloud7:"
2026/04/03 22:16:30 DEBUG : Using config file from "/home/gigi/.config/rclone/rclone.conf"
2026/04/03 22:16:30 DEBUG : You have specified to dump information. Please be noted that the Accept-Encoding as shown may not be correct in the request and the response may not show Content-Encoding if the go standard libraries auto gzip encoding was in effect. In this case the body of the request will be gunzipped before showing it.
2026/04/03 22:16:30 DEBUG : You have specified to dump information. Please be noted that the Accept-Encoding as shown may not be correct in the request and the response may not show Content-Encoding if the go standard libraries auto gzip encoding was in effect. In this case the body of the request will be gunzipped before showing it.
[
2026/04/03 22:16:30 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2026/04/03 22:16:30 DEBUG : HTTP REQUEST (req 0xc0000e8a00)
2026/04/03 22:16:30 DEBUG : GET /listfolder?folderid=0&recursive=1 HTTP/1.1
Host: eapi.pcloud.com
User-Agent: rclone/v1.73.3
Authorization: XXXX
Accept-Encoding: gzip

2026/04/03 22:16:30 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2026/04/03 22:16:30 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2026/04/03 22:16:30 DEBUG : HTTP RESPONSE (req 0xc0000e8a00)
2026/04/03 22:16:30 DEBUG : HTTP/1.1 200 OK
Connection: close
Content-Length: 49
Cache-Control: private, max-age=0
Content-Type: application/json; charset=utf-8
Date: Fri, 03 Apr 2026 19:16:30 GMT
Etag: "t0CMtHnrSSmWumtUOz57MbJ4tDlX"
Server: CloudHTTPd-API v1.1
Vary: Accept-Encoding
X-Error: 1101

2026/04/03 22:16:30 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2026/04/03 22:16:30 DEBUG : 5 go routines active
2026/04/03 22:16:30 NOTICE: Failed to lsjson: error in ListJSON: couldn't list files: pcloud error: Invalid request. (1101)

What happens here is that rclone is a partially out-of-date client of pClone.

This is nothing out of ordinary, it’s just business as usual.

1xxx These errors are reserved for cases when the API client misbehaved.

@asdffdsa, the section “Help and Support” is not appropriate for this topic. The failing command is a feature expected to work which is no longer working - it’s clearly an issue (i.e., out of date client).

i did some testing and i believe i narrowed down the issue to ListR functionality.
based on that i found a workaround

rclone lsjson pcloud01:  --disable=listR --recursive
rclone ls     pcloud01:  --disable=listR

i added that information to your github issue
https://github.com/rclone/rclone/issues/9315

1 Like

i did some more testing and i found another issue.
i will update the github issue as well.

i was looking at the --dump=bodies output and notice that the root directory is "id": "d0", not "id": "0"

  • --pcloud-root-folder-id=0, outputs DEBUG : Invalid directory id "0"
  • --pcloud-root-folder-id=d0, DOES NOT output that message

looking at the pcloud api
there are two choices for specifying the id of the directory, one is a string, one is a integer
maybe this is a hint to the underlying issue with rclone?

  • path string path to the folder
  • folderid int id of the folder
rclone lsjson pcloud01: -vv --pcloud-root-folder-id="0" 
DEBUG : rclone: Version "v1.73.3" starting with parameters ["d:\\data\\rclone\\rclone.exe" "lsjson" "pcloud01:" "-vv" "--pcloud-root-folder-id=0"]
DEBUG : Creating backend with remote "pcloud01:"
DEBUG : Using config file from "d:\\data\\rclone\\rclone.conf"
DEBUG : pcloud01: detected overridden config - adding "{Id8O8}" suffix to name
DEBUG : fs cache: renaming cache item "pcloud01:" to be canonical "pcloud01{Id8O8}:"
[
DEBUG : Invalid directory id "0"
{"Path":"zork","Name":"zork","Size":-1,"MimeType":"inode/directory","ModTime":"2026-04-06T15:47:19Z","IsDir":true,"ID":"d30962512646"}
]

-------------------------------------------------------

rclone lsjson pcloud01: -vv --pcloud-root-folder-id="d0" 
DEBUG : rclone: Version "v1.73.3" starting with parameters ["d:\\data\\rclone\\rclone.exe" "lsjson" "pcloud01:" "-vv" "--pcloud-root-folder-id=d0"]
DEBUG : Creating backend with remote "pcloud01:"
DEBUG : Using config file from "d:\\data\\rclone\\rclone.conf"
[
{"Path":"zork","Name":"zork","Size":-1,"MimeType":"inode/directory","ModTime":"2026-04-06T15:47:19Z","IsDir":true,"ID":"d30962512646"}
]