Rclone deadlocks running check against mounted pcloud directory

Suspected Bug
1

What is the problem you are having with rclone?

rclone hangs when trying to do a rclone check involving a rclone mounted filesystem

I'm unable to kill the process, even with kill -9 and I have to reboot to recover

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

rclone v1.68.2

  • os/version: fedora 42 (64 bit)
  • os/kernel: 6.14.2-300.fc42.x86_64 (x86_64)
  • os/type: linux
  • os/arch: amd64
  • go/version: go1.24.1
  • go/linking: dynamic
  • 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)

A rclone check against two cryptomator vaults: one is on the local filesystem and the other is mounted using rclone mount. This works well on my "test-vault" but this vault contains a lot more files and causes the error.

Rclone is running as a systemd service, started like so:

rclone rcd --log-file=/home/REDACTED/log/rclone.log --log-level INFO  --rc-no-auth --password-command='zenity --entry --hide-text --title "rclone config password"'

The command that causes it to hang is the check:

rclone rc operations/check srcFs=/home/REDACTED/mnt/cryptomator/docs-vault dstFs=/home/REDACTED/mnt/cryptomator/docs-vault-remote-ro _config='{"ModifyWindow": 2000000000}'

The rclone mount in question is the following:

rclone rc mount/mount fs=pcloud:/docs-vault mountPoint=/home/REDACTED/mnt/pcloud/docs-vault-remote-ro vfsOpt='{"ReadOnly": true, "PollInterval": 0, "DirCacheTime": 60000000000}

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
hostname = api.pcloud.com
token = XXX

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

There's nothing in the logs at INFO. I can run again with DEBUG if needed. Here is a dump from SIGQUIT:

2

This diagram might help explain the architecture a bit.

The goal is to be able to generate a diff of the files in the vault but be able to see the human-readable differences, hence the diff happening on the decrypted vaults. The check is what causes the issue.

image
image2091×1401 116 KB

3

It's possible that the bug is with the mount and not with the check, or maybe it's the interplay between the two.

Looking at the last line in the log I see this:

2025/04/20 18:53:44 DEBUG : d/RI/3KWTSV6HS3KSHD2K6G42L5S7GSNXD7: forgetting directory cache

Which makes me wonder if it's a dupe of this issue:

Here are the full DEBUG logs this time. You can see most of the logs have the encrypted filenames which are the cryptomator files it's reading via the mount:

4

welcome to the forum,

before calling this a bug, can rclone selfupdate and test again.

5

Thanks for teaching me about selfupdate

Now running this version:

2025/04/21 07:27:04 DEBUG : rclone: Version "v1.69.1" starting with parameters ["rclone" "rcd" "--log-file=/home/REDACTED/log/rclone.log" "--log-level" "DEBUG" "--rc-web-gui-no-open-browser" "--rc-web-gui" "--rc-no-auth" "--password-command=zenity --entry --hide-text --title \"rclone config password\""]
2025/04/21 07:27:05 DEBUG : Current tag: v2.0.5, Release tag: v2.0.5

I'm happy to report that it succeeded performing the check. I tried both with a 1 minute and a 1 day DirCacheTime and it succeeded both times.

The one thing that was very noticeable was that the rate at which the new version processed the files (as evidenced by nothing more than the rate at which the logs flew by) was immensely faster. I'll be curious to look in the changelogs and see if there was anything between these two versions that could be related.

Outside the scope of this suspected bug, but now I need to work on tuning the check and/or the mount. It passed, but seems to use a ton of network, CPU, and time. For a tree of 109 directories, 1377 files of size 679M it took several minutes and according to the stats, transferred 677.92 MB at 3.14 MBPS so it looks like to perform the check it needs to download the entire file.

I think it's safe to call this suspected bug resolved though. Will post back if it happens again.

6

welcome

great!

well, should look at the debug log?

can pick one single file and figure out what is going on.
run rclone check --size-only -vv and rclone check -vv

7

Upon reflection, I realized the flaw in my architecture diagram from the first reply: it's likely possible for rclone to perform a checksum check without downloading, but it's not possible for cryptomator to do so, because the checksum and size check is being performed on the decrypted file. Because the checksum check is happening on the mounted crypt, it indirectly forces an entire fetch of the file through the mount behind the scenes.

I think the solution here is to replace the mount with a simple sync. To get my human readable diff of the vault files on the cloud I must maintain a second copy which always reflects the remote files. That was effectively happening via mount with the cache, but required a re-fetch every time because the cache couldn't be trusted. It will cost two copies of the data on local disk, but that was happening anyway.

Thanks again. Super impressed with this software and community which I just discovered.

8

yeah, all that makes sense.

with keepass, that is what i do, nice and simple.
each time keepass starts, exits or saves a change, triggers a rclone sync --backup-dir

welcome!

9

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.