## Why this happens

This behavior is actually expected once you understand the flow:

- curl's "100%" progress bar only means **your client finished sending the bytes**. It says nothing about what the server did with them.
- transfer.sh only sends its HTTP response **after** it has received the file *and* written it to its storage backend (local disk, S3, etc.) and generated a token.
- An HTTP 500 means that final server-side step failed, so no download link was ever generated. Your upload was essentially discarded.

## Common causes

1. **The public instance is overloaded or broken.** The hosted `transfer.sh` service has historically been unstable and frequently returns 500s under load. This is the most common cause.
2. **File too large.** The public instance has a size cap (historically ~10 GB), and self-hosted instances may set lower limits. The server often accepts the whole stream, then fails when finalizing.
3. **Server-side storage failure.** Disk full, unwritable temp directory, or a failing S3/GCS backend.
4. **Timeout during post-upload processing** (reverse proxy or backend storage), especially with large files on slow connections.
5. **Transient error** — often a simple retry succeeds.

## How to diagnose

Run with verbose output and read the **response body** — transfer.sh usually returns an error message there:

```bash
curl -v --upload-file myfile.tar.gz https://transfer.sh/myfile.tar.gz
```

Test with a tiny file to isolate size-related failures:

```bash
echo test t.txt && curl --upload-file t.txt https://transfer.sh/t.txt
```

- Small file works, large file fails → size limit or timeout.
- Small file also fails with 500 → the server itself is broken; retry later or use another instance.

## Workarounds

- **Retry** a few times — transient 500s are common.
- **Split large files:**
```bash
split -b 2G bigfile.iso part_
```
- **Self-host** (it's open source):
```bash
docker run -d -p 8080:8080 dutchcoders/transfer.sh
curl --upload-file myfile http://localhost:8080/myfile
```
If your self-hosted instance 500s, check `docker logs`, `df -h` for disk space, write permissions on the basedir, and your storage provider config.
- **Use an alternative service**, e.g.:
```bash
curl -F'file=@myfile' https://0x0.st
```

Also consider adding `--fail` and `--retry 3` to your curl command so failures exit non-zero and are retried automatically in scripts.

Question

## Why this happens

This behavior is actually expected once you understand the flow:

- curl's "100%" progress bar only means **your client finished sending the bytes**. It says nothing about what the server did with them.
- transfer.sh only sends its HTTP response **after** it has received the file *and* written it to its storage backend (local disk, S3, etc.) and generated a token.
- An HTTP 500 means that final server-side step failed, so no download link was ever generated. Your upload was essentially discarded.

## Common causes

1. **The public instance is overloaded or broken.** The hosted `transfer.sh` service has historically been unstable and frequently returns 500s under load. This is the most common cause.
2. **File too large.** The public instance has a size cap (historically ~10 GB), and self-hosted instances may set lower limits. The server often accepts the whole stream, then fails when finalizing.
3. **Server-side storage failure.** Disk full, unwritable temp directory, or a failing S3/GCS backend.
4. **Timeout during post-upload processing** (reverse proxy or backend storage), especially with large files on slow connections.
5. **Transient error** — often a simple retry succeeds.

## How to diagnose

Run with verbose output and read the **response body** — transfer.sh usually returns an error message there:

```bash
curl -v --upload-file myfile.tar.gz https://transfer.sh/myfile.tar.gz
```

Test with a tiny file to isolate size-related failures:

```bash
echo test > t.txt && curl --upload-file t.txt https://transfer.sh/t.txt
```

- Small file works, large file fails → size limit or timeout.
- Small file also fails with 500 → the server itself is broken; retry later or use another instance.

## Workarounds

- **Retry** a few times — transient 500s are common.
- **Split large files:**
  ```bash
  split -b 2G bigfile.iso part_
  ```
- **Self-host** (it's open source):
  ```bash
  docker run -d -p 8080:8080 dutchcoders/transfer.sh
  curl --upload-file myfile http://localhost:8080/myfile
  ```
  If your self-hosted instance 500s, check `docker logs`, `df -h` for disk space, write permissions on the basedir, and your storage provider config.
- **Use an alternative service**, e.g.:
  ```bash
  curl -F'file=@myfile' https://0x0.st
  ```

Also consider adding `--fail` and `--retry 3` to your curl command so failures exit non-zero and are retried automatically in scripts.

Accepted Answer

这是 transfer.sh 服务端的故障，而不是本地上传问题。上传失败可能会返回 HTTP 500，并显示 `Could not save metadata`，包括在使用 `curl -vT file.txt https://transfer.sh` 时。一位维护者已确认该服务不可用（issue #594）。目前没有客户端的解决办法；请等待服务恢复后稍后重试。在脚本中依赖 transfer.sh 之前，请先检查其服务状态或其 GitHub issues，如果需要立即分享文件，请使用其他文件传输服务。

transfer.sh

核心功能

避坑指南

适用场景

详细介绍

常见问题与排障 (1)

标签

快速上手

相似推荐