Queue appears blank / items don’t appear

Symptom: The receiver queue is empty even though the sender has items queued.

Cause: This is usually a stale page or SSE connection issue.

Resolution:

  1. Refresh the receiver browser tab (F5 or Cmd+R)
  2. Check the connection status badge — if it shows Reconnecting or Disconnected, wait for it to turn green
  3. If the badge stays disconnected, verify the sender is still running
  4. If items were queued before the receiver connected, they should appear after the initial queue load on connect

“Invalid Date” or garbled text in queue

Symptom: Dates or text in the queue display as “Invalid Date” or appear garbled.

Cause: A browser caching or rendering issue, or a mismatch between an old receiver session and a new sender.

Resolution:

  1. Hard refresh the page: Ctrl+Shift+R (Windows/Linux) or Cmd+Shift+R (macOS)
  2. If the issue persists, clear browser cache for localhost
  3. Ensure the receiver URL and secret match the current sender session

404 on sender root / UI does not load

Symptom: Opening http://localhost:5000 shows a 404 or “connection refused”.

Cause: The sender is not running, or is running on a different port.

Resolution:

  1. Check if the sender process is still running in your terminal
  2. If it exited unexpectedly, restart it: cloud-share-sender
  3. If you started with a custom port, use that port: http://localhost:<port>

File or text size exceeded

Symptom: Upload fails with:

  Error: File exceeds maximum size of 100 MB

or

  Error: Text exceeds maximum size of 10 MB

Cause: The content is larger than the allowed limit.

TypeLimit
Text10 MB
File100 MB
Zip bundle100 MB

Resolution:

  • For text: split into smaller chunks, or save as a file and use file transfer
  • For files: compress the file first, split it with split (Linux/macOS) or 7-Zip (Windows), or use a different transfer mechanism for very large files
  • For zips: remove some files from the bundle and send in multiple transfers

Zip password forgotten

Symptom: The receiver downloaded a zip bundle but cannot open it — the password is not known.

Cause: The zip password was set by the sender but not communicated to the receiver, or was forgotten.

Resolution:

The zip password cannot be recovered — it is not stored anywhere in the cloud-share system. The sender must:

  1. Re-create the zip bundle with a new (known) password
  2. Queue the new bundle
  3. Communicate the new password to the receiver through a secure channel

Getting more diagnostic information

For any issue not covered here, run with verbose logging to see detailed output:

  # Sender
cloud-share-sender --log verbose

# Receiver
cloud-share-receiver --log verbose

Verbose logging shows:

  • DevTunnels CLI output and tunnel creation steps
  • All incoming HTTP requests and responses
  • SSE connection events and reconnection attempts
  • Encryption and hash computation steps (without revealing plaintext)