Practical guide

Diagnose a failed client download before sending more links

Last materially reviewed 2026-09-29

Quick answerIdentify whether the failure is access, transfer, unpacking or file use; each boundary needs a different check.
What to know

Ask for the observed step

Did the link fail to open, did the transfer stop, did an archive fail to unpack or did the final file fail in an application? Ask for a safe description of the message and relevant device context. Avoid requesting screenshots that expose unrelated client information. The location of the failure is more useful than a general statement that the files do not work.

What to know

Check the smallest plausible cause

Review the exact link, its intended availability and any relevant traffic or permission limit. For a transferred package, consider local space and the expected file type. Do not change several settings at once or repeatedly send replacement links without understanding the result. Those actions can create competing versions while leaving the original problem unresolved.

What to know

Preserve the release

Keep the accepted source package unchanged while diagnosing the recipient route. If a correction is needed, issue a clearly identified replacement with an explanation. Do not delete the old material as a speculative fix or tell the client to bypass a browser security warning. Follow supported troubleshooting and the client’s own device policies.

What to know

A fictional diagnosis

A client downloads a ZIP but reports failure when opening the source document inside it. The transfer itself may be complete; the next question concerns the expected application and included dependencies. Sending the same archive through three services is unlikely to clarify that. Record what was observed, resolve the compatibility issue and confirm the specific task rather than announcing a universal service failure.

What to know

Put the decision into practice

Preserve a concise troubleshooting history: observed step, one relevant change and resulting observation. Redact private details before seeking external assistance. If the cause remains uncertain, keep the release unchanged and follow supported help rather than repeatedly altering permissions, disabling security controls or deleting files to start again.

Continue when useful

Next: Recipient check

Observe the intended recipient task with a harmless sample; an owner’s successful preview does not establish that a client can retrieve and use the release.

Open Recipient check →

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. pCloud shared links — Merchant documentation · help.pcloud.com · Merchant-controlled · checked 2026-09-29
  2. pCloud file transfer and organization — Merchant documentation · help.pcloud.com · Merchant-controlled · checked 2026-09-29