rclone 列 pCloud 根目录报 1101，先区分根递归与子目录递归

pCloud 的根目录能普通列举，进入某个子目录也能递归，偏偏从根目录执行 --fast-list --recursive 就报 1101。这种组合值得先检查根目录递归请求。rclone 1.73.3 在 Ubuntu 25.04、连接 eapi.pcloud.com 的环境里出现过这一故障；不能据此把所有 pCloud 列表失败都归入同一原因。

pCloud 对 folderid=0 的根目录限制递归请求。继续重试同一个根递归请求不会改变这个限制。rclone 的修正路径先普通列出根目录，再分别递归其子目录，把结果合并返回；正式 1.74.0 已包含这项处理，也把相关 1101 错误归为不应反复重试的请求失败。

先用已有 remote 做只读对照。下面的 pcloud: 是示例名称，已有子目录 要换成确实存在且可访问的目录：

rclone version
rclone lsf pcloud:
rclone lsjson pcloud: --fast-list --recursive
rclone lsjson 'pcloud:已有子目录' --fast-list --recursive

分别记录退出码与错误文本。若普通根列表和子目录递归成功，只有根递归出现 1101，症状与这个限制相符。若连普通列表也失败，应先处理凭据、权限或远端连接；若子目录返回其他错误，也不能用根目录修复解释它。

升级到包含该修复、适合部署环境的维护版本，再重复相同的只读命令。1.74.0 是已确认包含修复的版本，不要求长期停留在这个版本。升级时确认定时任务、容器和手动命令实际调用的是同一份二进制，避免命令行已经更新，后台任务仍使用旧程序。

暂时无法升级时，可以在相关命令中禁用 ListR，采用逐目录列举：

rclone lsjson pcloud: --recursive --disable ListR

这种兼容方式会改变请求组织，目录较多时可能增加 API 调用与等待时间，应按实际目录规模观察。不要把“重试次数更多”当作修复，也不要从一个远端案例推算所有账号的性能。

验收要检查完整性：根文件是否存在、已有子目录里的文件是否被递归列出，以及命令是否仍报 1101。只看退出码为零不够；可挑几个已知路径与普通子目录列表交叉核对。其他 pCloud API 错误、超大目录的失败或网络限流，应按各自的错误与请求路径继续诊断。