Solve transfer problems
Check the specific problem instead of starting over: a quick decision list and the common symptoms with their next step.
Quick decision
- Sign-in or approval fails: check the account, the expiry time, the service permission and, if relevant, the device request.
- The receiver does not appear: check the right installation, the active device release, receive rights and the destination catalog.
- The connection is unclear: open the info icon, keep the target active and check again within limits.
- The receiver reports a storage problem: solve space or rights at the target; switching to the server route does not fix that.
- The connection was briefly interrupted: resume the existing job; do not use a new transfer as the standard retry.
- Received, but the file is not in the Files app: check the local export and the save dialog; receiving and saving are different steps.
Common symptoms and what to do
| Symptom or code | What it means | A sensible next step |
|---|---|---|
| No sign-in email arrives | The address, mailbox delivery or the account release can be missing | Check the address and spam, respect the waiting time shown; give support the time and the address you used through a private channel, never the code |
| “Confirm action” | The action needs a fresh confirmation | Enter the email code in the dialog; a complete sign-out is not the standard fix |
login_required, invalid_grant | The session or native permission is missing or no longer valid | Use the normal sign-in or authorization flow; do not work around a revocation with refresh loops |
| Device request invalid at once | The request can have expired, been processed already or been rejected because of a server-side requirement | Check the latest request and its release status; report the time and version, and do not assume a particular cause without a diagnosis |
| Receiving device not ready yet | The target has not accepted yet or is not actively ready to receive | Open the browser and check acceptance; for a service, check the inbox and the exact sender release |
| Direct not confirmed | A probe is missing, has expired or a checked route failed | Read the details, activate the receiver, check again; choose the server route deliberately if needed |
| Server route although on the same Wi-Fi | Belonging to a Wi-Fi network does not prove a reachable, authenticated direct route | Check guest isolation, VPN, firewall, browser profile and the method actually used |
destination_pending | The destination publication is not confirmed yet | On B run destinations sync; reconcile the same intent |
destination_unavailable | Alias, rights or revision no longer match or are not usable | Reread the destination catalog and have B check; do not redirect an existing transfer unnoticed |
receiver_blocked | The receiver reported a verified reason | Read receiver_status and the allowed next actions, for example fix space or rights |
| Storage full | The receiver, local browser space or a holding area can be affected | Free space on the side named; resume the existing job after approval |
| Write permission missing | The actual service user may not write to the location | Fix the rights on B and test under that identity; do not start everything as root |
| Quota or HTTP 429 | A budget or a limited operation is used up | Note the error code and the retry period; ask for the budget to be released if needed. Clearing the local cache does not lift server quotas |
| Speed test HTTP 429 | Diagnostic calls are limited in time and budget | Keep to the waiting time given; use the support report you already have |
installation_busy | Another process owns the installation | Use the right daemon or CLI control path; do not open the same state in parallel |
daemon_unavailable | The private service channel is not available | Check your own service status, user and state |
server_mismatch | This installation was signed in against a different pipeit address | Sign in again with this installation |
timeout | The time budget is used up; the state may still exist | Read the status and resume with the same ID. Choose a suitable time budget on slow networks |
| Folder source changed | The originals no longer match the prepared crypto plan | Keep the sources unchanged or start a new job deliberately |
| iOS saves a technical name | The browser export cannot pass the original name | If offered, use “Save file” and the system dialog; use Safari or rename afterwards if needed |
| “Download started” but nothing visible | A browser export does not confirm the final location | Check Downloads, the Files app and permissions; save the local copy again |
| Activation or management pending | File delivery and the following action have separate states | Read the action status and finish the required review or approval |
Scroll sideways to see the whole table.
Do not explain codes by the HTTP status alone: a 429 at sign-in is something different from an exhausted streaming quota or a speed-test cooldown. The actual server response decides.
When the transfer is slow
First open the connection details: which route actually ran? Then check whether the time goes into preparing, sending, receiving or finishing. Wi-Fi, VPN, CPU, disks and many small files act differently. With several devices, make one manageable comparison on the same sources and known routes. See Speed test and support report.
What helps us help you
- The time with time zone, the client, browser and OS version, and the roles involved: sender or receiver.
- The transfer, group or action ID and a support ID, where available, through the private support channel.
- The route you wanted and the one actually used, fallback allowed or forbidden, the visible error code.
- The order of magnitude, the number of files and the file or folder profile; private file names are normally not needed.
- The phase of the failure and whether the receiver was open or the service active.
- Whether it happened after a network change, a browser reload, sleep or a version change.
What should not happen automatically
Do not reset the whole device pairing, clear caches, switch off security software or open firewall rules across the board. Fix the specific problem first. Rebuild device access removes access from old devices and is a separate recovery step, not a routine repair for a slow network.
Related guides
- Apps and browser
Check the connection and look back at it later
See which route is checked before sending and which one was actually used afterwards.
- Command line and servers
Speed test and support report
Run a deliberate, limited measurement and keep the support ID for a conversation with us.
- Command line and servers
Status, progress and resuming
Read the state of a transfer and continue the same job instead of starting a new one.
Still stuck?
Check the troubleshooting guide first. If that does not help, tell us what happened.