Unable to download attachment after uploading via mobile client (Android/iOS) #1084

New Issue

OVERLORD · 2025-10-09T17:03:15+03:00

OVERLORD commented

2025-10-09 17:03:15 +03:00

Originally created by @Tieneks on GitHub.

Subject of the issue

Unable to download attachment after uploading via Android app. Downloading after uploading via web vault causes no issues.

Deployment environment

vaultwarden version:
v1.25.1

Install method:
Docker image on Synology NAS
Clients used:
Web vault, Android app
Reverse proxy and version:
MySQL/MariaDB or PostgreSQL version:
SQLite
Other relevant details:

Steps to reproduce

Upload an attachment (to personal item or organisation) via Android app.
Try to download on Android app afterwards: "Cannot download file".
Sync with server.
Try to download in webvault.
Popup shows correct name and size of attachment.
Download attachment: 1kb file regardsless.
The attached file does show up on the server in data/attachments/[FOLDER] with an expected size.

Expected behaviour

Uploading an attachment via the Android app should allow you to download the attachment later from any client.

Actual behaviour

The attachment is "gone" after uploading it via the Android app, cannot be downloaded and can only be removed.

Troubleshooting data

Your environment (Generated via diagnostics page)

Vaultwarden version: v1.25.1
Web-vault version: v2022.6.2
Running within Docker: true (Base: Debian)
Environment settings overridden: false
Uses a reverse proxy: true
IP Header check: true (X-Real-IP)
Internet access: true
Internet access via a proxy: false
DNS Check: true
Time Check: true
Domain Configuration Check: true
HTTPS Check: true
Database type: SQLite
Database version: 3.35.4
Clients used:
Reverse proxy and version:
Other relevant information:

Config (Generated via diagnostics page)

Show Running Config

Environment settings which are overridden:

{
  "_duo_akey": null,
  "_enable_duo": false,
  "_enable_email_2fa": true,
  "_enable_smtp": true,
  "_enable_yubico": false,
  "_ip_header_enabled": true,
  "admin_ratelimit_max_burst": 3,
  "admin_ratelimit_seconds": 300,
  "admin_token": "***",
  "allowed_iframe_ancestors": "",
  "attachments_folder": "data/attachments",
  "authenticator_disable_time_drift": false,
  "data_folder": "data",
  "database_conn_init": "",
  "database_max_conns": 10,
  "database_timeout": 30,
  "database_url": "****/**.*******",
  "db_connection_retries": 15,
  "disable_2fa_remember": false,
  "disable_admin_token": false,
  "disable_icon_download": false,
  "domain": "*****://***.**/",
  "domain_origin": "*****://***.**",
  "domain_path": "",
  "domain_set": true,
  "duo_host": null,
  "duo_ikey": null,
  "duo_skey": null,
  "email_attempts_limit": 3,
  "email_expiration_time": 600,
  "email_token_size": 6,
  "emergency_access_allowed": true,
  "emergency_notification_reminder_schedule": "0 5 * * * *",
  "emergency_request_timeout_schedule": "0 5 * * * *",
  "enable_db_wal": true,
  "extended_logging": true,
  "helo_name": null,
  "hibp_api_key": null,
  "icon_blacklist_non_global_ips": true,
  "icon_blacklist_regex": null,
  "icon_cache_folder": "data/icon_cache",
  "icon_cache_negttl": 259200,
  "icon_cache_ttl": 2592000,
  "icon_download_timeout": 10,
  "icon_redirect_code": 302,
  "icon_service": "internal",
  "incomplete_2fa_schedule": "30 * * * * *",
  "incomplete_2fa_time_limit": 3,
  "invitation_org_name": "Vaultwarden",
  "invitations_allowed": true,
  "ip_header": "X-Real-IP",
  "job_poll_interval_ms": 30000,
  "log_file": null,
  "log_level": "Info",
  "log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f",
  "login_ratelimit_max_burst": 10,
  "login_ratelimit_seconds": 60,
  "org_attachment_limit": null,
  "org_creation_users": "*************@*****.***, ******@*********.***",
  "password_hints_allowed": true,
  "password_iterations": 100000,
  "reload_templates": false,
  "require_device_email": false,
  "rsa_key_filename": "data/rsa_key",
  "send_purge_schedule": "0 5 * * * *",
  "sends_allowed": true,
  "sends_folder": "data/sends",
  "show_password_hint": true,
  "signups_allowed": false,
  "signups_domains_whitelist": "*******.**, *********.***",
  "signups_verify": false,
  "signups_verify_resend_limit": 3,
  "signups_verify_resend_time": 3600,
  "smtp_accept_invalid_certs": false,
  "smtp_accept_invalid_hostnames": false,
  "smtp_auth_mechanism": null,
  "smtp_debug": false,
  "smtp_explicit_tls": false,
  "smtp_from": "**********@***.**",
  "smtp_from_name": "Vaultwarden",
  "smtp_host": "*******.***.**",
  "smtp_password": "***",
  "smtp_port": 25,
  "smtp_security": "off",
  "smtp_ssl": false,
  "smtp_timeout": 15,
  "smtp_username": "**********@***.**",
  "templates_folder": "data/templates",
  "tmp_folder": "data/tmp",
  "trash_auto_delete_days": 28,
  "trash_purge_schedule": "0 5 0 * * *",
  "use_syslog": false,
  "user_attachment_limit": null,
  "web_vault_enabled": true,
  "web_vault_folder": "web-vault/",
  "websocket_address": "0.0.0.0",
  "websocket_enabled": false,
  "websocket_port": 3012,
  "yubico_client_id": null,
  "yubico_secret_key": null,
  "yubico_server": null
}

Originally created by @Tieneks on GitHub.   ### Subject of the issue  Unable to download attachment after uploading via Android app. Downloading after uploading via web vault causes no issues. ### Deployment environment     * vaultwarden version: v1.25.1  * Install method: Docker image on Synology NAS * Clients used:  Web vault, Android app * Reverse proxy and version:  * MySQL/MariaDB or PostgreSQL version:  SQLite * Other relevant details: ### Steps to reproduce  * Upload an attachment (to personal item or organisation) via Android app. * Try to download on Android app afterwards: "Cannot download file". * Sync with server. * Try to download in webvault. Popup shows correct name and size of attachment. * Download attachment: 1kb file regardsless. The attached file does show up on the server in data/attachments/[FOLDER] with an expected size. ### Expected behaviour  Uploading an attachment via the Android app should allow you to download the attachment later from any client. ### Actual behaviour  The attachment is "gone" after uploading it via the Android app, cannot be downloaded and can only be removed. ### Troubleshooting data  ### Your environment (Generated via diagnostics page) * Vaultwarden version: v1.25.1 * Web-vault version: v2022.6.2 * Running within Docker: true (Base: Debian) * Environment settings overridden: false * Uses a reverse proxy: true * IP Header check: true (X-Real-IP) * Internet access: true * Internet access via a proxy: false * DNS Check: true * Time Check: true * Domain Configuration Check: true * HTTPS Check: true * Database type: SQLite * Database version: 3.35.4 * Clients used: * Reverse proxy and version: * Other relevant information: ### Config (Generated via diagnostics page) <details><summary>Show Running Config</summary> **Environment settings which are overridden:** ```json { "_duo_akey": null, "_enable_duo": false, "_enable_email_2fa": true, "_enable_smtp": true, "_enable_yubico": false, "_ip_header_enabled": true, "admin_ratelimit_max_burst": 3, "admin_ratelimit_seconds": 300, "admin_token": "***", "allowed_iframe_ancestors": "", "attachments_folder": "data/attachments", "authenticator_disable_time_drift": false, "data_folder": "data", "database_conn_init": "", "database_max_conns": 10, "database_timeout": 30, "database_url": "****/**.*******", "db_connection_retries": 15, "disable_2fa_remember": false, "disable_admin_token": false, "disable_icon_download": false, "domain": "*****://***.**/", "domain_origin": "*****://***.**", "domain_path": "", "domain_set": true, "duo_host": null, "duo_ikey": null, "duo_skey": null, "email_attempts_limit": 3, "email_expiration_time": 600, "email_token_size": 6, "emergency_access_allowed": true, "emergency_notification_reminder_schedule": "0 5 * * * *", "emergency_request_timeout_schedule": "0 5 * * * *", "enable_db_wal": true, "extended_logging": true, "helo_name": null, "hibp_api_key": null, "icon_blacklist_non_global_ips": true, "icon_blacklist_regex": null, "icon_cache_folder": "data/icon_cache", "icon_cache_negttl": 259200, "icon_cache_ttl": 2592000, "icon_download_timeout": 10, "icon_redirect_code": 302, "icon_service": "internal", "incomplete_2fa_schedule": "30 * * * * *", "incomplete_2fa_time_limit": 3, "invitation_org_name": "Vaultwarden", "invitations_allowed": true, "ip_header": "X-Real-IP", "job_poll_interval_ms": 30000, "log_file": null, "log_level": "Info", "log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f", "login_ratelimit_max_burst": 10, "login_ratelimit_seconds": 60, "org_attachment_limit": null, "org_creation_users": "*************@*****.***, ******@*********.***", "password_hints_allowed": true, "password_iterations": 100000, "reload_templates": false, "require_device_email": false, "rsa_key_filename": "data/rsa_key", "send_purge_schedule": "0 5 * * * *", "sends_allowed": true, "sends_folder": "data/sends", "show_password_hint": true, "signups_allowed": false, "signups_domains_whitelist": "*******.**, *********.***", "signups_verify": false, "signups_verify_resend_limit": 3, "signups_verify_resend_time": 3600, "smtp_accept_invalid_certs": false, "smtp_accept_invalid_hostnames": false, "smtp_auth_mechanism": null, "smtp_debug": false, "smtp_explicit_tls": false, "smtp_from": "**********@***.**", "smtp_from_name": "Vaultwarden", "smtp_host": "*******.***.**", "smtp_password": "***", "smtp_port": 25, "smtp_security": "off", "smtp_ssl": false, "smtp_timeout": 15, "smtp_username": "**********@***.**", "templates_folder": "data/templates", "tmp_folder": "data/tmp", "trash_auto_delete_days": 28, "trash_purge_schedule": "0 5 0 * * *", "use_syslog": false, "user_attachment_limit": null, "web_vault_enabled": true, "web_vault_folder": "web-vault/", "websocket_address": "0.0.0.0", "websocket_enabled": false, "websocket_port": 3012, "yubico_client_id": null, "yubico_secret_key": null, "yubico_server": null } ``` </details>

OVERLORD added the troubleshooting bug labels 2025-10-09 17:03:15 +03:00

OVERLORD closed this issue

2025-10-09 17:03:16 +03:00

OVERLORD commented

2025-10-09 17:03:17 +03:00

@tmeckel commented on GitHub:

I'm not sure if this is related, but when I try to upload an attachment via the WebVault the following pop-up is shown:

@tmeckel commented on GitHub: I'm not sure if this is related, but when I try to upload an attachment via the WebVault the following pop-up is shown: ![image](https://user-images.githubusercontent.com/14177833/180992745-ae9e3ec7-4cd3-4b45-a681-6afd90b891d9.png)

OVERLORD commented

2025-10-09 17:03:17 +03:00

@tmeckel commented on GitHub:

@Tieneks Okay, so unrelated 👍🏼

@tmeckel commented on GitHub: @Tieneks Okay, so unrelated 👍🏼

OVERLORD commented

2025-10-09 17:03:18 +03:00

@Tieneks commented on GitHub:

I'm not sure if this is related, but when I try to upload an attachment via the WebVault the following pop-up is shown:

I do not get this error when uploading via the web vault.

@Tieneks commented on GitHub: > I'm not sure if this is related, but when I try to upload an attachment via the WebVault the following pop-up is shown: > > ![image](https://user-images.githubusercontent.com/14177833/180992745-ae9e3ec7-4cd3-4b45-a681-6afd90b891d9.png) I do not get this error when uploading via the web vault.

OVERLORD commented

2025-10-09 17:03:18 +03:00

@BlackDex commented on GitHub:

@Tieneks well, i have it patched, but not fixed.
With the latest version you will not be able to upload files via the mobile clients anymore.
That at least solves the issue of broken files, while a successful upload was reported.

We are looking into a better way to actually fix this.

@BlackDex commented on GitHub: @Tieneks well, i have it patched, but not fixed. With the latest version you will not be able to upload files via the mobile clients anymore. That at least solves the issue of broken files, while a successful upload was reported. We are looking into a better way to actually fix this.

OVERLORD commented

2025-10-09 17:03:19 +03:00

@BlackDex commented on GitHub:

@Tieneks Hmm that is strange.
There seems to be something wrong with either the data transfered or stored.
Not sure yet what/how/why

@BlackDex commented on GitHub: @Tieneks Hmm that is strange. There seems to be something wrong with either the data transfered or stored. Not sure yet what/how/why

OVERLORD commented

2025-10-09 17:03:19 +03:00

@BlackDex commented on GitHub:

@hendrik1120 works fine for me. I suggest to check the reverse proxy settings and logs.
Also try to use the developer mode to debug the extension.

@BlackDex commented on GitHub: @hendrik1120 works fine for me. I suggest to check the reverse proxy settings and logs. Also try to use the developer mode to debug the extension.

OVERLORD commented

2025-10-09 17:03:20 +03:00

@Tieneks commented on GitHub:

@Tieneks well, i have it patched, but not fixed. With the latest version you will not be able to upload files via the mobile clients anymore. That at least solves the issue of broken files, while a successful upload was reported.

We are looking into a better way to actually fix this.

I tested it and am getting an error message, as expected. Now at least the file won't "disappear".
It's not possible to upload a file as an attachment or Send from the Android app. When I upload a file via the web interface, I am able to download the file via the Android app. Again, as expected.

tl;dr:
Patch works as expected.

@Tieneks commented on GitHub: > @Tieneks well, i have it patched, but not fixed. With the latest version you will not be able to upload files via the mobile clients anymore. That at least solves the issue of broken files, while a successful upload was reported. > > We are looking into a better way to actually fix this. I tested it and am getting an error message, as expected. Now at least the file won't "disappear". It's not possible to upload a file as an attachment or Send from the Android app. When I upload a file via the web interface, I am able to download the file via the Android app. Again, as expected. tl;dr: Patch works as expected.

OVERLORD commented

2025-10-09 17:03:20 +03:00

@hendrik1120 commented on GitHub:

It also happens with the chrome extension and even files saved months before are getting downloaded as 8 byte files.
This is gamebreaking. How are people supposed to get their security certs?

Edit: Same with the safari extension

@hendrik1120 commented on GitHub: It also happens with the chrome extension and even files saved months before are getting downloaded as 8 byte files. This is gamebreaking. How are people supposed to get their security certs? Edit: Same with the safari extension

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/vaultwarden#1084