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

Not listed? See the 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

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.

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:

# 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:

# 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:

# 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:

rclone ls danubedata:your-bucket

See the rclone section 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.

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 — 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 — 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:
  BashCopy

  # 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:

[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:

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

# 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:

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:

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:

# 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:

[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:

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

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:

# 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:

[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:
  INICopy

  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

# 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:
  BashCopy

  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

# 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:

# 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:

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 for more troubleshooting.

Duplicati on Unraid

If you run Duplicati as a Docker container on Unraid, follow the Duplicati section 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:
  TextCopy

  /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 — 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