# Object Storage Migration Troubleshooting

Troubleshooting guide for NAS, backup, and sync tools after the DanubeData Object Storage backend migration from MinIO to Ceph.

## Quick Navigation

| NAS / Appliances | Backup Software | CLI / Sync Tools |
|------------------|-----------------|------------------|
| [TrueNAS](#truenas) | [Veeam](#veeam) | [rclone](#rclone) |
| [Synology](#synology) | [Duplicati](#duplicati) | [Restic](#restic) |
| [QNAP](#qnap) | [MSP360 (CloudBerry)](#msp360-cloudberry-backup) | [s3cmd](#s3cmd) |
| [Unraid](#unraid) | [Acronis Cyber Protect](#acronis-cyber-protect) | [AWS CLI](#aws-cli) |
| [Asustor](#asustor) | [Arq Backup](#arq-backup) | [MinIO Client (mc)](#minio-client-mc) |
| [TerraMaster](#terramaster) | [Kopia](#kopia) | [Cyberduck](#cyberduck) |
| [Proxmox](#proxmox-backup-server) | | |

Not listed? See the [General Checklist](#general-checklist) at the bottom.

---

## What Changed

DanubeData Object Storage has migrated from MinIO to Ceph RGW. The S3 API remains fully compatible, but some tools may require minor configuration adjustments. Your endpoint, access keys, and bucket names remain the same.

### Key Differences

| Area | Before (MinIO) | After (Ceph RGW) |
|------|----------------|-------------------|
| **URL Style** | Path-style and virtual-hosted | Path-style and virtual-hosted |
| **Signature** | AWS Signature v4 | AWS Signature v4 or v2 |
| **Multipart Threshold** | 5 GB max part | 5 GB max part |
| **SSL Certificate** | Same domain | Same domain, new certificate chain |

> **Note**: Both AWS Signature v4 and Signature v2 are supported. Prefer v4, which is the stronger scheme, unless your client cannot sign correctly with it — see [S3 Signature Requirements](object-storage-signature-requirements).

## Common Issues

### SSL/TLS Certificate Errors

After migration, some clients cache the old TLS certificate. Symptoms include `SSL certificate problem`, `certificate verify failed`, or `CERTIFICATE_VERIFY_FAILED`.

**Fix:**

```bash
# Clear the system CA cache (Linux)
sudo update-ca-certificates

# Clear the system CA cache (macOS)
sudo security delete-certificate -Z <old-cert-hash>

# Or simply restart the application/service to pick up the new certificate
```

For appliances (NAS devices), restart the backup service or reboot the device to refresh the certificate store.

### "Access Denied" After Migration

If your credentials were working before but now return `403 Access Denied`:

1. Verify your access key and secret key are correct (re-enter them in your tool)
2. Ensure you are using **AWS Signature v4** (not v2)
3. Set the region to `fsn1` if your tool requires a region
4. Confirm the endpoint is `https://s3.danubedata.ro`

### "Bucket Not Found" or "NoSuchBucket"

Bucket names have not changed, but some tools cache bucket metadata. Clear the tool's cache or re-enter the bucket name manually.

### Slow Uploads or Timeouts

Ceph RGW may handle multipart uploads slightly differently. If you experience timeouts:

- Increase the multipart chunk size (e.g., from 5 MB to 64 MB)
- Increase the connection timeout in your client
- Reduce the number of parallel upload threads if the tool allows it

---

## TrueNAS

TrueNAS uses **Cloud Sync Tasks** to back up to S3-compatible storage.

### Reconfiguring Cloud Credentials

1. Go to **Credentials > Cloud Credentials**
2. Edit your DanubeData credential (or create a new one)
3. Set:
   - **Provider**: Amazon S3
   - **Access Key ID**: your access key
   - **Secret Access Key**: your secret key
   - **Endpoint URL**: `https://s3.danubedata.ro`
4. Under **Advanced Settings**:
   - **Region**: leave empty or set to `fsn1`
   - Leave **Use Signature v2** unchecked (v4 is preferred; v2 also works)
5. Click **Verify Credential** to test the connection
6. Save

### Troubleshooting Cloud Sync Tasks

**"InvalidArgument" or "AuthorizationHeaderMalformed"**
- Try toggling **Use Signature v2** — both signature versions are supported

**"Connection timed out"**
- Verify the endpoint URL includes `https://` (not `http://`)
- Check that TrueNAS can resolve `s3.danubedata.ro` (try `ping s3.danubedata.ro` from the TrueNAS shell)

**"SSL: CERTIFICATE_VERIFY_FAILED"**
- Go to **System > General > GUI > SSL** and update the CA certificates, or reboot TrueNAS to refresh the certificate store

**Cloud Sync stuck at 0%**
- Delete and recreate the Cloud Sync task with fresh credentials
- Check the task log at **Tasks > Cloud Sync Tasks > View Logs**

---

## Proxmox Backup Server

Proxmox Backup Server (PBS) supports S3 storage via **datastore** backends or by using **rclone** for offsite copies.

### Proxmox VE (S3 via Storage Configuration)

Proxmox VE does not natively support S3 as a backup target. If you are using a script or wrapper to push backups to S3:

1. Update your script's S3 configuration to use AWS Signature v4
2. Ensure the endpoint is `https://s3.danubedata.ro`
3. Test with a manual upload:

```bash
# From the Proxmox host
s3cmd --host=s3.danubedata.ro --host-bucket="%(bucket)s.s3.danubedata.ro" \
  --access_key=YOUR_KEY --secret_key=YOUR_SECRET \
  --signature-v2=False \
  put /tmp/testfile s3://your-bucket/testfile
```

### Using rclone on Proxmox

If you use rclone to sync Proxmox backups to DanubeData:

```bash
# Update your rclone config (~/.config/rclone/rclone.conf)
[danubedata]
type = s3
provider = Other
access_key_id = YOUR_ACCESS_KEY
secret_access_key = YOUR_SECRET_KEY
endpoint = https://s3.danubedata.ro
region = fsn1
```

Verify the connection:

```bash
rclone ls danubedata:your-bucket
```

See the [rclone section](#rclone) below for more troubleshooting.

---

## Synology

Synology NAS supports S3 storage via **Hyper Backup** and **Cloud Sync**.

### Hyper Backup

Hyper Backup needs **Signature Version 2** against DanubeData Object Storage, and a task's signature
version cannot be edited after the task is created. Full setup instructions, and how to move an
existing task without re-uploading your data, are on the dedicated page:
**[Synology Hyper Backup](synology-hyper-backup)**.

### Cloud Sync

1. Open **Cloud Sync**
2. Edit your existing connection
3. Set:
   - **S3 Server**: Custom
   - **Server Address**: `https://s3.danubedata.ro`
   - **Signature Version**: **V4**
4. Re-enter your credentials
5. Click **Test Connection** before saving

If uploads fail with `403 AccessDenied` while downloads still work, see [S3 Signature Requirements](object-storage-signature-requirements) — some clients need **V2**.

**"Connection failed" in Cloud Sync**
- Older DSM versions may not support the new certificate chain. Update DSM, or manually import DanubeData's CA certificate via **Control Panel > Security > Certificates**

---

## QNAP

QNAP uses **Hybrid Backup Sync (HBS 3)** for S3 cloud backups.

### Reconfiguring HBS 3

1. Open **HBS 3 (Hybrid Backup Sync)**
2. Go to **Storage Spaces** in the left sidebar
3. Edit your existing S3-compatible storage space (or create a new one)
4. Configure:
   - **Server Address**: `s3.danubedata.ro`
   - **Port**: `443`
   - **Access Key**: your access key
   - **Secret Key**: your secret key
   - **Use SSL**: Enabled
   - **Signature Version**: **V4**
5. Click **Test** to verify the connection
6. Select your bucket and save

### Troubleshooting

**"Connection failed" or "Unable to list buckets"**
- Ensure **Signature Version** is set to **V4**
- If uploads fail with `403 AccessDenied` while downloads still work, see [S3 Signature Requirements](object-storage-signature-requirements) — some clients need **V2**
- Ensure **Use SSL** is enabled
- Verify the server address is exactly `s3.danubedata.ro` (no `https://` prefix, no trailing slash)

**"Access Denied" on backup job**
- Re-enter the secret key (some QNAP firmware versions mask and re-encode the key incorrectly after edits)
- Create a fresh storage space rather than editing the existing one

**Backup jobs failing intermittently**
- Increase the **Timeout** value in the backup job's advanced settings
- Reduce the **Concurrent Connections** to 2-4

---

## Veeam

Veeam Backup & Replication supports S3-compatible storage as an **Object Storage Repository**.

### Reconfiguring the S3 Repository

1. Open **Veeam Backup & Replication Console**
2. Go to **Backup Infrastructure > Backup Repositories**
3. Edit your S3-compatible repository
4. On the **Account** step:
   - Re-enter your **Access Key** and **Secret Key**
   - Ensure the **Service Point** is `https://s3.danubedata.ro`
   - Set **Region** to `fsn1` (or `us-east-1` if `fsn1` is not accepted)
5. On the **Bucket** step, re-select your bucket
6. Finish the wizard

### Troubleshooting

**"Failed to connect to the endpoint"**
- Veeam requires the endpoint with `https://` prefix
- Ensure port 443 is not blocked by your firewall

**"The request signature we calculated does not match"**
- Re-enter both the access key and secret key (copy-paste to avoid typos)
- Ensure no proxy is modifying request headers

**"The specified bucket does not exist"**
- Click **Browse** to refresh the bucket list rather than typing the name manually

**Backup jobs failing with "Internal Server Error"**
- Check if the backup is using very small block sizes. Increase the block size in the backup job settings
- Ensure Veeam is up to date (minimum v12 recommended for best S3 compatibility)

---

## Duplicati

Duplicati supports S3-compatible storage as a backup destination.

### Reconfiguring Duplicati

1. Open **Duplicati Web UI**
2. Edit your backup configuration
3. Under **Storage Type**, select **S3 Compatible**
4. Configure:
   - **Server**: Custom URL
   - **Custom URL**: `s3.danubedata.ro`
   - **Bucket Name**: your bucket name
   - **AWS Access ID**: your access key
   - **AWS Access Key**: your secret key
   - **Region**: `fsn1`
5. Under **Advanced Options**, ensure:
   - `--s3-ext-signatureversion=4` is set
6. Click **Test Connection**

### Troubleshooting

**"AuthorizationHeaderMalformed"**
- Add the advanced option: `--s3-ext-signatureversion=4`

**"SSL certificate problem"**
- On the machine running Duplicati, update the CA certificates:
  ```bash
  # Linux
  sudo update-ca-certificates

  # Windows
  certutil -generateSSTFromWU roots.sst
  ```
- Or add the advanced option `--accept-any-ssl-certificate=true` (not recommended for production)

**"A socket operation was attempted to an unreachable network"**
- Verify DNS resolution: `nslookup s3.danubedata.ro`
- Verify HTTPS connectivity: `curl -I https://s3.danubedata.ro`

---

## rclone

rclone is widely used for syncing data to S3-compatible storage.

### Configuration

Update your rclone remote in `~/.config/rclone/rclone.conf`:

```ini
[danubedata]
type = s3
provider = Other
access_key_id = YOUR_ACCESS_KEY
secret_access_key = YOUR_SECRET_KEY
endpoint = https://s3.danubedata.ro
region = fsn1
acl = private
```

Or reconfigure interactively:

```bash
rclone config update danubedata \
  type=s3 \
  provider=Other \
  access_key_id=YOUR_ACCESS_KEY \
  secret_access_key=YOUR_SECRET_KEY \
  endpoint=https://s3.danubedata.ro \
  region=fsn1
```

### Verify

```bash
# List buckets
rclone lsd danubedata:

# List objects in a bucket
rclone ls danubedata:your-bucket

# Test upload
echo "test" | rclone rcat danubedata:your-bucket/migration-test.txt
rclone delete danubedata:your-bucket/migration-test.txt
```

### Troubleshooting

**"AccessDenied" or "SignatureDoesNotMatch"**
- Ensure `provider = Other` (not `Minio`). Some rclone versions send MinIO-specific headers when provider is set to `Minio`
- Remove any `force_path_style` setting (it defaults to `true` for provider `Other`)

**"NoSuchBucket" when bucket exists**
- Set `region = fsn1` explicitly in the config

**Slow transfers**
- Increase chunk size: add `chunk_size = 64M` to the remote config
- Increase transfer concurrency: `rclone copy --transfers 8 --s3-upload-concurrency 4 ...`

**"Checksum mismatch" errors**
- Add `--s3-disable-checksum` to your rclone command
- Or add `disable_checksum = true` to the remote config

---

## Restic

Restic supports S3-compatible storage as a backup repository.

### Configuration

Set the environment variables:

```bash
export AWS_ACCESS_KEY_ID=YOUR_ACCESS_KEY
export AWS_SECRET_ACCESS_KEY=YOUR_SECRET_KEY
export RESTIC_REPOSITORY=s3:https://s3.danubedata.ro/your-bucket
```

Or specify them inline:

```bash
restic -r s3:https://s3.danubedata.ro/your-bucket snapshots
```

### Migrating an Existing Repository

If you had a Restic repository on the old backend, it should continue to work without changes. Verify:

```bash
# Check repository integrity
restic -r s3:https://s3.danubedata.ro/your-bucket check

# List snapshots
restic -r s3:https://s3.danubedata.ro/your-bucket snapshots
```

### Troubleshooting

**"client.PutObject: Access Denied"**
- Re-export your credentials and ensure they are correct
- Ensure the bucket exists and your access key has write permissions

**"TLS handshake timeout"**
- Check your network connectivity to `s3.danubedata.ro`
- If running behind a corporate proxy, configure `HTTP_PROXY` / `HTTPS_PROXY` environment variables

**"repository master key and target key mismatch"**
- This means the repository data was partially migrated or corrupted. Run `restic check` and if it reports errors, restore from an alternate backup

**Slow backup performance**
- Increase the connection limit: `restic -o s3.connections=10 backup ...`

---

## s3cmd

s3cmd is a popular command-line tool for S3.

### Configuration

Update `~/.s3cfg`:

```ini
[default]
access_key = YOUR_ACCESS_KEY
secret_key = YOUR_SECRET_KEY
host_base = s3.danubedata.ro
host_bucket = %(bucket)s.s3.danubedata.ro
use_https = True
signature_v2 = False
```

Or reconfigure:

```bash
s3cmd --configure \
  --host=s3.danubedata.ro \
  --host-bucket="%(bucket)s.s3.danubedata.ro" \
  --access_key=YOUR_KEY \
  --secret_key=YOUR_SECRET
```

### Troubleshooting

**"S3 error: 403 (SignatureDoesNotMatch)"**
- Ensure `signature_v2 = False` in `~/.s3cfg`

**"S3 error: 404 (NoSuchBucket)"**
- Check that `host_bucket` is set correctly. If virtual-hosted style fails, try path-style by setting `host_bucket =` (empty value)

---

## AWS CLI

The AWS CLI (`aws s3` / `aws s3api`) works with any S3-compatible endpoint.

### Configuration

```bash
aws configure --profile danubedata
# Access Key ID: YOUR_ACCESS_KEY
# Secret Access Key: YOUR_SECRET_KEY
# Default region: fsn1
# Default output format: json
```

Use the `--endpoint-url` flag for all commands:

```bash
# List buckets
aws --profile danubedata --endpoint-url https://s3.danubedata.ro s3 ls

# List objects
aws --profile danubedata --endpoint-url https://s3.danubedata.ro s3 ls s3://your-bucket

# Upload a file
aws --profile danubedata --endpoint-url https://s3.danubedata.ro s3 cp /tmp/testfile s3://your-bucket/testfile
```

To avoid passing `--endpoint-url` every time, set it in `~/.aws/config`:

```ini
[profile danubedata]
region = fsn1
endpoint_url = https://s3.danubedata.ro
s3 =
  signature_version = s3v4
```

### Troubleshooting

**"An error occurred (SignatureDoesNotMatch)"**
- Ensure signature version is v4. Add to your profile in `~/.aws/config`:
  ```ini
  s3 =
    signature_version = s3v4
  ```

**"Could not connect to the endpoint URL"**
- Verify you are passing `--endpoint-url https://s3.danubedata.ro` (not the default AWS endpoint)
- If using `endpoint_url` in config, ensure you are on AWS CLI v2 (v1 does not support `endpoint_url` in config)

**"An error occurred (NoSuchBucket)"**
- Set `region = fsn1` in your profile or pass `--region fsn1`

---

## MinIO Client (mc)

If you were using the MinIO Client (`mc`) with the old backend, it will continue to work with Ceph RGW.

### Configuration

```bash
# Update your existing alias
mc alias set danubedata https://s3.danubedata.ro YOUR_ACCESS_KEY YOUR_SECRET_KEY

# Verify
mc ls danubedata
```

### Troubleshooting

**"Unable to validate credentials"**
- Remove and re-create the alias:
  ```bash
  mc alias remove danubedata
  mc alias set danubedata https://s3.danubedata.ro YOUR_ACCESS_KEY YOUR_SECRET_KEY
  ```

**"S3 API Requests must be made to API port"**
- Ensure the endpoint includes `https://` and does not include a port number (port 443 is implied)

**Admin commands (`mc admin`) no longer work**
- `mc admin` commands are MinIO-specific and do not work with Ceph RGW. Use the DanubeData dashboard or S3 API for bucket management

---

## Cyberduck

Cyberduck is a graphical file transfer client for macOS and Windows with S3 support.

### Configuration

1. Open **Cyberduck**
2. Click **Open Connection** (or edit an existing bookmark)
3. Select **Amazon S3** from the dropdown
4. Configure:
   - **Server**: `s3.danubedata.ro`
   - **Port**: `443`
   - **Access Key ID**: your access key
   - **Secret Access Key**: your secret key
5. Click **Connect**

### Troubleshooting

**"Login failed" or "403 Forbidden"**
- Go to **Preferences > S3** and ensure **Signature Version** is set to **AWS4-HMAC-SHA256 (Signature Version 4)**
- Delete the saved password from macOS Keychain or Windows Credential Manager and re-enter it

**Bucket listing is empty**
- Cyberduck uses `us-east-1` as the default region. Edit the bookmark and set the **Region** field to `fsn1`
- Alternatively, type the bucket name directly in the **Path** field: `/your-bucket`

**"Connection timed out"**
- Verify that the protocol is HTTPS (not HTTP) and the port is 443
- Check if a local firewall or proxy is blocking the connection

---

## MSP360 (CloudBerry) Backup

MSP360 (formerly CloudBerry) Backup supports S3-compatible storage for file, image, and database backups.

### Reconfiguring the S3 Account

1. Open **MSP360 Backup**
2. Go to **Backup Storage** (or **Storage Accounts**)
3. Edit your existing S3-compatible account (or add a new one)
4. Configure:
   - **S3 Compatible**: selected
   - **Service Point**: `s3.danubedata.ro`
   - **Access Key**: your access key
   - **Secret Key**: your secret key
   - **Use SSL**: Enabled
   - **Signature Version**: **4**
   - **Bucket**: select your bucket
5. Click **Test Connection**
6. Save

### Troubleshooting

**"The request signature we calculated does not match the signature you provided"**
- Edit the storage account and ensure **Signature Version** is set to **4**

**"SSL/TLS secure channel could not be established"**
- Update your OS to get the latest CA certificates
- On Windows: run Windows Update. On macOS: update macOS via System Preferences

**Backup plan fails with "Access Denied" but test connection works**
- The backup plan may be running under a different Windows user account (e.g., SYSTEM) that has different credentials stored. Re-enter the storage account credentials in the MSP360 service context

**"The specified bucket does not exist"**
- Clear the local bucket cache: go to **Tools > Options > Cache** and click **Clear Cache**, then re-select the bucket

---

## Acronis Cyber Protect

Acronis supports S3-compatible storage as a backup destination for cloud and local backup plans.

### Reconfiguring S3 Storage

1. Open the **Acronis Management Console** (or **Cyber Protect Console**)
2. Go to **Settings > Backup Storage**
3. Edit your S3-compatible storage location
4. Update:
   - **Service URL**: `https://s3.danubedata.ro`
   - **Access Key**: your access key
   - **Secret Key**: your secret key
   - **Bucket**: re-select your bucket
   - **Region**: `fsn1`
5. Click **Test Connection**
6. Save

### Troubleshooting

**"Failed to initialize the storage"**
- Acronis may cache connection metadata. Remove the storage location and add it again from scratch
- Ensure the URL includes `https://`

**"The storage is unavailable"**
- Verify that the Acronis agent service has network access to `s3.danubedata.ro` on port 443
- If the agent runs on a server behind a proxy, configure the proxy in Acronis agent settings

**Backup fails with "Part upload error"**
- Reduce the **Multipart Upload Size** in the storage's advanced settings (e.g., from 128 MB to 64 MB)
- Increase the **Connection Timeout** value

**Existing backups show as "corrupted" after migration**
- Run **Validate Backup** on the affected backup set. If Acronis reports the archive as valid, the error is a stale cache — clear the agent cache and retry

---

## Arq Backup

Arq Backup (macOS and Windows) supports S3-compatible storage for encrypted backups.

### Configuration

1. Open **Arq Backup**
2. Go to **Destinations**
3. Edit your existing destination (or add a new one)
4. Select **S3-Compatible** as the type
5. Configure:
   - **Server URL**: `https://s3.danubedata.ro`
   - **Access Key ID**: your access key
   - **Secret Access Key**: your secret key
   - **Region**: `fsn1`
   - **Path Style**: Enabled
6. Select your bucket
7. Save

### Troubleshooting

**"Unable to list buckets"**
- Enable **Path Style** access in the destination settings
- Set the region to `fsn1` (Arq may default to `us-east-1`)

**"Authentication error" on existing backup set**
- Edit the destination, re-enter the secret key, and click **Test**
- If the error persists, check that no other Arq instance is writing to the same bucket concurrently

**Backup verification fails**
- Run **Verify Backup Data** from the **Backups** menu. Arq stores its own index files in the bucket — if any were in transit during migration, a verify-and-repair cycle will fix them

---

## Kopia

Kopia is a modern backup tool with native S3-compatible storage support.

### Configuration

```bash
# Connect to an existing repository
kopia repository connect s3 \
  --bucket=your-bucket \
  --access-key=YOUR_ACCESS_KEY \
  --secret-access-key=YOUR_SECRET_KEY \
  --endpoint=s3.danubedata.ro \
  --region=fsn1

# Or create a new repository
kopia repository create s3 \
  --bucket=your-bucket \
  --access-key=YOUR_ACCESS_KEY \
  --secret-access-key=YOUR_SECRET_KEY \
  --endpoint=s3.danubedata.ro \
  --region=fsn1
```

### Migrating an Existing Repository

If you had a Kopia repository on the old backend:

```bash
# Reconnect to the repository
kopia repository connect s3 \
  --bucket=your-bucket \
  --access-key=YOUR_ACCESS_KEY \
  --secret-access-key=YOUR_SECRET_KEY \
  --endpoint=s3.danubedata.ro \
  --region=fsn1

# Verify repository integrity
kopia repository validate-provider

# List snapshots
kopia snapshot list
```

### Troubleshooting

**"unable to open repository"**
- Ensure the endpoint does not include a trailing slash
- Re-enter the access key and secret key

**"repository not initialized in the provided storage"**
- This means Kopia cannot find its metadata files. Verify the bucket name and prefix path are correct

**"invalid credentials"**
- Kopia caches credentials locally. Run `kopia repository disconnect` and then reconnect with fresh credentials

---

## Unraid

Unraid supports S3 backup via community plugins, most commonly **Appdata Backup** with rclone or **Duplicati** as a Docker container.

### rclone (via User Scripts or CLI)

If you use rclone on Unraid to sync shares or appdata to S3:

1. SSH into your Unraid server
2. Update the rclone config:

```bash
rclone config update danubedata \
  type=s3 \
  provider=Other \
  access_key_id=YOUR_ACCESS_KEY \
  secret_access_key=YOUR_SECRET_KEY \
  endpoint=https://s3.danubedata.ro \
  region=fsn1
```

3. Verify: `rclone lsd danubedata:`

See the [rclone section](#rclone) for more troubleshooting.

### Duplicati on Unraid

If you run Duplicati as a Docker container on Unraid, follow the [Duplicati section](#duplicati) above. One Unraid-specific note:

**Certificate errors inside the Duplicati container**
- The container has its own CA store. Update the container image to the latest version, or mount the host's CA certificates:
  ```
  /etc/ssl/certs:/etc/ssl/certs:ro
  ```

### CA Certificate Plugin

If any S3 tool on Unraid reports certificate errors, install the **CA User Scripts** or **NerdTools** plugin from Community Applications to update the system CA bundle.

---

## Asustor

Asustor NAS uses **DataSync Center** and **Backup Plan** for S3 cloud backups.

### Reconfiguring DataSync Center

1. Open **DataSync Center** from ADM
2. Go to **Cloud Backup** and edit your existing S3 task
3. Select **S3 Compatible** as the cloud service
4. Configure:
   - **Server**: `s3.danubedata.ro`
   - **Port**: `443`
   - **SSL**: Enabled
   - **Access Key**: your access key
   - **Secret Key**: your secret key
   - **Signature Version**: **V4**
5. Select your bucket
6. Click **Test Connection**
7. Save

### Troubleshooting

**"Connection failed"**
- Ensure the server field does not include `https://` (DataSync Center adds it when SSL is enabled)
- Ensure **Signature Version** is set to **V4**
- If uploads fail with `403 AccessDenied` while downloads still work, see [S3 Signature Requirements](object-storage-signature-requirements) — some clients need **V2**

**"Failed to authenticate"**
- Re-enter both keys. Asustor may store credentials in an encrypted format that is invalidated after firmware updates
- Update ADM to the latest version

**Backup jobs stuck or not starting**
- Restart the DataSync Center service: go to **Services > DataSync Center** and toggle it off and on
- Check the ADM system log at **Access Control > Logs** for detailed error messages

---

## TerraMaster

TerraMaster NAS uses **TFM Backup** and **CloudSync** for S3 cloud backups.

### Reconfiguring TFM Backup

1. Open **TFM Backup** from the TOS desktop
2. Edit your existing cloud backup task
3. Select **S3 Compatible** as the destination
4. Configure:
   - **Server Address**: `s3.danubedata.ro`
   - **Port**: `443`
   - **Use SSL/TLS**: Enabled
   - **Access Key**: your access key
   - **Secret Key**: your secret key
   - **Bucket**: select your bucket
5. Save and run a test backup

### Troubleshooting

**"Connection error" or "Unable to connect to server"**
- Verify the server address has no `https://` prefix and no trailing slash
- Ensure **Use SSL/TLS** is enabled
- Update TOS to the latest version for certificate chain compatibility

**"Authentication failed"**
- Delete the existing cloud backup destination and create a new one with fresh credentials
- TerraMaster firmware prior to TOS 5.1 may have issues with AWS Signature v4 — update firmware first

**Backup appears to complete but no files are uploaded**
- Check the bucket in the DanubeData dashboard to confirm files arrived
- Some TOS versions create an empty task when the connection test passes but the actual upload path is misconfigured. Re-enter the bucket name manually instead of selecting from the dropdown

---

## General Checklist

If your tool is not listed above, follow this general checklist:

1. **Endpoint**: `https://s3.danubedata.ro`
2. **Region**: `fsn1` (or leave empty if the tool does not require it; use `us-east-1` as a fallback if `fsn1` is rejected)
3. **Signature Version**: AWS Signature **v4** (not v2)
4. **SSL/TLS**: Enabled (port 443)
5. **Access Key & Secret Key**: Re-enter them (do not copy from cached config)
6. **Path Style**: Use path-style URLs if your tool supports it (`https://s3.danubedata.ro/bucket`)
7. **Test**: Upload a small test file before running a full backup

If you continue to experience issues after following these steps, contact support at **support@danubedata.ro** with:
- The tool name and version
- The exact error message
- Your bucket name (not your secret key)

---

**Questions?** Contact support at support@danubedata.ro