# Check checksum support and scope before rclone cryptcheck > rclone cryptcheck requires checksum support from the encrypted remote’s underlying backend, and one-way checking does not detect destination-only extra files. - Canonical URL: https://update.dsesecurity.com/updates/check-checksum-support-and-scope-before-rclone-cryptcheck/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-28T23:23:20+00:00 - Modified: 2026-10-28T23:23:38+00:00 - Last reviewed by DSE: 2026-10-28 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, IT - Reading time: 3 minutes ## What you need to know rclone cryptcheck requires checksum support from the encrypted remote’s underlying backend, and one-way checking does not detect destination-only extra files. ## Potentially affected Review scope: the current rclone cryptcheck command reference; backend, client version and intended comparison direction require confirmation. ## DSE recommendation DSE recommends documenting the comparison endpoints, backend capability and treatment of extra files before accepting an encrypted-copy integrity report. ## Article Bottom line: DSE recommendation: decide what the comparison must establish before accepting its report as evidence about an encrypted copy. Record which side is the source, which side is being checked and whether extra destination files matter to the owner’s acceptance criteria. ## Source fact: what the authority says The [rclone cryptcheck reference](https://rclone.org/commands/rclone_cryptcheck/) requires checksum support from the encrypted remote’s underlying backend. With the documented --one-way flag, extra destination files that are absent from the source are not detected. The reference describes reports for matching files, differences and files missing from either side. ## What the source does not establish This command reference does not establish that a particular backend provides the required capability or that a source is still available. A comparison result is not a retention decision, a complete service recovery test or permission to change files. This article does not approve a sync, deletion or repair operation. ## Applicability questions - Which client version, underlying backend and encrypted remote are in the proposed comparison? - What source is authoritative for this exercise, and who has approved access to its data? - Must the review identify extra destination files, missing source files, differing content or all of these? - What remote access, transfer costs and handling restrictions need an owner’s review before testing? ## DSE recommendation: controlled next steps The following paragraphs are DSE recommendations, not instructions or guarantees from the source. Define three logical fixture items: A has matching content in both sets; B has deliberately different content; C exists only at the destination. These are proposed test inputs, not observed files or results. State which differences the owner needs the review to identify, especially whether item C belongs in the acceptance question. Confirm the backend checksum prerequisite in its current official documentation before preparing the exercise. Record the reviewed client, underlying backend and encrypted remote. Explain the comparison direction in plain language. If the required capability or the authoritative source population cannot be established, stop rather than interpreting an unsuitable check as evidence. Keep the exercise observational. Record the selected mode and the expected scope alongside the three-item matrix. Assign a person to investigate unexplained differences and protect file paths in shared reports. Obtain separate approval for any later action on the data; the comparison plan does not authorize sync, deletion or repair. ## Verification and evidence Proposed verification, not a performed test: prepare the nonsensitive A, B and C fixture in an approved test remote. Rehearse the intended comparison and retain the actual reports for the matching, changed and destination-only populations. With --one-way selected, destination-only item C is outside the documented check. If the owner requires C to be identified, do not accept that mode as proof of the wider requirement. Retain the endpoint identities, prerequisite evidence, client version, invocation and selected mode with the starting matrix and redacted observations. Have a second operator explain each population and any untested condition. Investigate disagreement before accepting the comparison. Keep subsequent data remediation and restoration under separate plans; none of these proposed cases establishes a completed recovery exercise. ## Official references - [rclone — rclone cryptcheck](https://rclone.org/commands/rclone_cryptcheck/) — official product documentation; source version and applicability limits are stated above. Source review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: rclone — rclone cryptcheck - Authority: rclone.org - URL: https://rclone.org/commands/rclone_cryptcheck/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Check checksum support and scope before rclone cryptcheck,” DSE Security, https://update.dsesecurity.com/updates/check-checksum-support-and-scope-before-rclone-cryptcheck/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.