Originally created by @vherrlein on GitHub (Oct 15, 2021).
Subject of the issue
Hi,
When you tries to use the send feature through Web UI or iOS app with files and any kind of settings (defaults, different expiry, deletion date and so on), an error occurs with the following message.
Originally created by @vherrlein on GitHub (Oct 15, 2021).
<!--
# ###
NOTE: Please update to the latest version of vaultwarden before reporting an issue!
This saves you and us a lot of time and troubleshooting.
See:
* https://github.com/dani-garcia/vaultwarden/issues/1180
* https://github.com/dani-garcia/vaultwarden/wiki/Updating-the-vaultwarden-image
# ###
-->
<!--
Please fill out the following template to make solving your problem easier and faster for us.
This is only a guideline. If you think that parts are unnecessary for your issue, feel free to remove them.
Remember to hide/redact personal or confidential information,
such as passwords, IP addresses, and DNS names as appropriate.
-->
### Subject of the issue
<!-- Describe your issue here. -->
Hi,
When you tries to use the send feature through Web UI or iOS app with files and any kind of settings (defaults, different expiry, deletion date and so on), an error occurs with the following message.
Os: { code: 61, kind: Other, message: “No data available” }
### Deployment environment
<!--
=========================================================================================
Preferably, use the `Generate Support String` button on the admin page's Diagnostics tab.
That will auto-generate most of the info requested in this section.
=========================================================================================
-->
<!-- The version number, obtained from the logs (at startup) or the admin diagnostics page -->
<!-- This is NOT the version number shown on the web vault, which is versioned separately from vaultwarden -->
<!-- Remember to check if your issue exists on the latest version first! -->
* vaultwarden version:
<!-- How the server was installed: Docker image, OS package, built from source, etc. -->
* Install method: Kubernetes via Helm Chart
* Clients used: <!-- web vault, desktop, Android, iOS, etc. (if applicable) --> web vault, desktop and iOS
* Reverse proxy and version: <!-- if applicable -->HA Proxy as TCP load balancer in front of Kubernetes cluster + Traefik as reverse proxy
* MySQL/MariaDB or PostgreSQL version: <!-- if applicable -->Default SQL Lite
* Other relevant details:
### Steps to reproduce
<!-- Tell us how to reproduce this issue. What parameters did you set (differently from the defaults)
and how did you start vaultwarden? -->
Using default Send interface, set title and file to upload then click on save.
### Expected behaviour
<!-- Tell us what you expected to happen -->
Saving the send record.
### Actual behaviour
<!-- Tell us what actually happened -->
Error message and the interface stays in the saving form.
error message: Os: { code: 61, kind: Other, message: “No data available” }
### Troubleshooting data
<!-- Share any log files, screenshots, or other relevant troubleshooting data -->
### Your environment (Generated via diagnostics page)
* Vaultwarden version: v1.22.2
* Web-vault version: v2.21.1
* Running within Docker: false
* Environment settings overridden: false
* Uses a reverse proxy: true
* IP Header check: false (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": false,
"_enable_smtp": false,
"_enable_yubico": true,
"_ip_header_enabled": true,
"admin_token": "***",
"allowed_iframe_ancestors": "",
"attachments_folder": "config/attachments",
"authenticator_disable_time_drift": false,
"data_folder": "config",
"database_max_conns": 10,
"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,
"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": "config/icon_cache",
"icon_cache_negttl": 259200,
"icon_cache_ttl": 2592000,
"icon_download_timeout": 10,
"invitation_org_name": "********",
"invitations_allowed": true,
"ip_header": "Cf-Connecting-Ip",
"job_poll_interval_ms": 30000,
"log_file": null,
"log_level": "Info",
"log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f",
"org_attachment_limit": null,
"org_creation_users": "",
"password_iterations": 100000,
"reload_templates": false,
"require_device_email": false,
"rsa_key_filename": "config/rsa_key",
"send_purge_schedule": "0 5 * * * *",
"sends_allowed": true,
"sends_folder": "config/sends",
"show_password_hint": false,
"signups_allowed": false,
"signups_domains_whitelist": "",
"signups_verify": false,
"signups_verify_resend_limit": 6,
"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": "Bitwarden",
"smtp_host": "****-*****-****",
"smtp_password": null,
"smtp_port": 8025,
"smtp_ssl": false,
"smtp_timeout": 15,
"smtp_username": null,
"templates_folder": "config/templates",
"trash_auto_delete_days": null,
"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>
Looks like your reverse proxy, or cloudflare is blocking something. Either the size is too large or something else. What happens if you try to take cloudflare out of the loop
@BlackDex commented on GitHub (Oct 15, 2021):
Looks like your reverse proxy, or cloudflare is blocking something. Either the size is too large or something else. What happens if you try to take cloudflare out of the loop
The error message is the same with any king of file sizes. (From 10KB to 100MB)
@vherrlein commented on GitHub (Oct 15, 2021):
I tried from :
1. Internet over Cloudflare - HA Proxy - Traefik
2. Local Network over HA Proxy - Traefik
3. Internal Kubernetes Network over Traefik
The error message is the same with any king of file sizes. (From 10KB to 100MB)
I Still think it is something locally.
Maybe you can try to enable the trace log_level and see what happens during the uploading of the file.
You should see something like this:
And there will probably be some more [multipart::server:: rows there, depending on the size of the file you upload. So i suggest for the testing to use a very small file.
@BlackDex commented on GitHub (Oct 15, 2021):
I Still think it is something locally.
Maybe you can try to enable the trace log_level and see what happens during the uploading of the file.
You should see something like this:
```
[2021-10-15 10:01:53.142][request][INFO] POST /api/sends/file
[2021-10-15 10:01:53.143][multipart::server][INFO] Multipart::with_boundary(_, "---------------------------36953251402733360120362257797")
[2021-10-15 10:01:53.143][multipart::server::field][DEBUG] ReadEntry::read_entry()
[2021-10-15 10:01:53.143][multipart::server][DEBUG] Consume boundary!
[2021-10-15 10:01:53.143][multipart::server::boundary][DEBUG] Boundary not found yet
[2021-10-15 10:01:53.143][hyper::http::h1][TRACE] Sized read, remaining=1134
[2021-10-15 10:01:53.143][hyper::http::h1][TRACE] Sized read: 1134
[2021-10-15 10:01:53.143][multipart::server::boundary][TRACE] Buf: "-----------------------------36953251402733360120362257797\r\nContent-Disposition: form-data; name=\"model\"\r\n\r\n{\"type\":1,\"fileLength\":689,\"name\":\"2.AEl...G9/oE6xMQ==|a5q4...4Q==|AB...6M/iWtZCMxhOJhM=\",\"notes\":null,\"maxAccessCount\":null,\"expirationDate\":null,\"deletionDate\":\"2021-10-22T08:01:40.000Z\",\"key\":\"2.U...w==|/N...E=\",\"disabled\":false,\"hideEmail\":false,\"file\":{\"response\":null,\"fileName\":\"2.d...Q==|V...Q==|2...M=\"}}\r\n-----------------------------36953251402733360120362257797\r\nContent-Disposition: form-data; name=\"data\"; filename=\"2.d...Q==|V...Q==|2...M=\"\r\nContent-Type: application/octet-stream\r\n\r\n\u{2}5g�On\u{2}���<~�...\u{366}O!��\r\n-----------------------------36953251402733360120362257797--\r\n"
[2021-10-15 10:01:53.144][multipart::server::boundary][DEBUG] Before search Buf len: 1646 Search idx: 0 State: Searching
[2021-10-15 10:01:53.144][multipart::server::boundary][DEBUG] After search Buf len: 1646 Search idx: 0 State: BoundaryRead
[2021-10-15 10:01:53.144][multipart::server::boundary][TRACE] Returning buf: ""
```
And there will probably be some more `[multipart::server::` rows there, depending on the size of the file you upload. So i suggest for the testing to use a very small file.
Sorry for the delay, now I have access to the environment.
Please find below the trace logs.
[2021-10-16 17:42:09.733][request][INFO] POST /api/sends/file/v2
[2021-10-16 17:42:09.733][response][INFO] 404 Not Found
[2021-10-16 17:42:09.746][request][INFO] POST /api/sends/file
[2021-10-16 17:42:09.751][multipart::server][INFO] Multipart::with_boundary(_, "----WebKitFormBoundaryLh45AOA7KTt2zean")
[2021-10-16 17:42:09.764][vaultwarden::api::core::sends][ERROR] Error: Os { code: 61, kind: Other, message: "No data available" }
[2021-10-16 17:42:09.765][response][INFO] POST /api/sends/file multipart/form-data (post_send_file) => 400 Bad Request
@vherrlein commented on GitHub (Oct 16, 2021):
Sorry for the delay, now I have access to the environment.
Please find below the trace logs.
```
[2021-10-16 17:42:09.733][request][INFO] POST /api/sends/file/v2
[2021-10-16 17:42:09.733][response][INFO] 404 Not Found
[2021-10-16 17:42:09.746][request][INFO] POST /api/sends/file
[2021-10-16 17:42:09.751][multipart::server][INFO] Multipart::with_boundary(_, "----WebKitFormBoundaryLh45AOA7KTt2zean")
[2021-10-16 17:42:09.764][vaultwarden::api::core::sends][ERROR] Error: Os { code: 61, kind: Other, message: "No data available" }
[2021-10-16 17:42:09.765][response][INFO] POST /api/sends/file multipart/form-data (post_send_file) => 400 Bad Request
```
I discovered the main trouble.
My Kubernetes infra had an issue with CoreDNS, a previous maintenance ops removed its config map which put my storage provider "GlusterFS" under an unstable state.
Then when the Pod relying to vaultwarden restarted, it was only able to list partially the persistent disk tree.
The error message "Os { code: 61, kind: Other, message: "No data available" }" came from POSIX commands.
I'm closing that issue.
Thanks allot for your help.
@vherrlein commented on GitHub (Oct 16, 2021):
Ho my......
I discovered the main trouble.
My Kubernetes infra had an issue with CoreDNS, a previous maintenance ops removed its config map which put my storage provider "GlusterFS" under an unstable state.
Then when the Pod relying to vaultwarden restarted, it was only able to list partially the persistent disk tree.
The error message "Os { code: 61, kind: Other, message: "No data available" }" came from POSIX commands.
I'm closing that issue.
Thanks allot for your help.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @vherrlein on GitHub (Oct 15, 2021).
Subject of the issue
Hi,
When you tries to use the send feature through Web UI or iOS app with files and any kind of settings (defaults, different expiry, deletion date and so on), an error occurs with the following message.
Os: { code: 61, kind: Other, message: “No data available” }
Deployment environment
Install method: Kubernetes via Helm Chart
Clients used: web vault, desktop and iOS
Reverse proxy and version: HA Proxy as TCP load balancer in front of Kubernetes cluster + Traefik as reverse proxy
MySQL/MariaDB or PostgreSQL version: Default SQL Lite
Other relevant details:
Steps to reproduce
Using default Send interface, set title and file to upload then click on save.
Expected behaviour
Saving the send record.
Actual behaviour
Error message and the interface stays in the saving form.
error message: Os: { code: 61, kind: Other, message: “No data available” }
Troubleshooting data
Your environment (Generated via diagnostics page)
Config (Generated via diagnostics page)
Show Running Config
Environment settings which are overridden:
@vherrlein commented on GitHub (Oct 15, 2021):
Note: Text Sends works as expected.
@BlackDex commented on GitHub (Oct 15, 2021):
Looks like your reverse proxy, or cloudflare is blocking something. Either the size is too large or something else. What happens if you try to take cloudflare out of the loop
@vherrlein commented on GitHub (Oct 15, 2021):
I tried from :
The error message is the same with any king of file sizes. (From 10KB to 100MB)
@BlackDex commented on GitHub (Oct 15, 2021):
I Still think it is something locally.
Maybe you can try to enable the trace log_level and see what happens during the uploading of the file.
You should see something like this:
And there will probably be some more
[multipart::server::rows there, depending on the size of the file you upload. So i suggest for the testing to use a very small file.@vherrlein commented on GitHub (Oct 16, 2021):
Sorry for the delay, now I have access to the environment.
Please find below the trace logs.
@vherrlein commented on GitHub (Oct 16, 2021):
Another tries with:
Debug Version:
Trace Version:
@vherrlein commented on GitHub (Oct 16, 2021):
Ho my......
I discovered the main trouble.
My Kubernetes infra had an issue with CoreDNS, a previous maintenance ops removed its config map which put my storage provider "GlusterFS" under an unstable state.
Then when the Pod relying to vaultwarden restarted, it was only able to list partially the persistent disk tree.
The error message "Os { code: 61, kind: Other, message: "No data available" }" came from POSIX commands.
I'm closing that issue.
Thanks allot for your help.