starred/vaultwarden
1
0
Fork 0
mirror of https://github.com/dani-garcia/vaultwarden.git synced 2026-02-05 00:29:40 +03:00
Code Issues 32 Packages Projects Releases 10 Wiki Activity

I can`t open attachments #335

New Issue
Closed
opened 2026-02-04 19:42:12 +03:00 by OVERLORD · 18 comments
OVERLORD commented 2026-02-04 19:42:12 +03:00
Owner
Copy Link

Originally created by @gerroon on GitHub (Jul 12, 2019).

Hi

I am using the Docker image. I have attachments in some entries (image, pdfs etc) When I try to open them in the web app , I am getting the errors below, I get An Error Occured in the page

[2019-07-12 16:14:45][rocket::rocket][INFO] GET /api/sync?excludeDomains=true/attachments/e2d7725b-d771-4e2e-9e55-97ccb0fe64b3/f5b823f0078a67c2b358:
[2019-07-12 16:14:45][_][INFO] Matched: GET /api/sync?<data..> (sync)
[2019-07-12 16:14:45][bitwarden_rs::auth][ERROR] Unauthorized Error: No access token provided
[2019-07-12 16:14:45][_][INFO] Outcome: Failure
[2019-07-12 16:14:45][_][WARN] Responding with 401 Unauthorized catcher.
[2019-07-12 16:14:45][_][INFO] Response succeeded.
Originally created by @gerroon on GitHub (Jul 12, 2019). Hi I am using the Docker image. I have attachments in some entries (image, pdfs etc) When I try to open them in the web app , I am getting the errors below, I get `An Error Occured` in the page ``` [2019-07-12 16:14:45][rocket::rocket][INFO] GET /api/sync?excludeDomains=true/attachments/e2d7725b-d771-4e2e-9e55-97ccb0fe64b3/f5b823f0078a67c2b358: [2019-07-12 16:14:45][_][INFO] Matched: GET /api/sync?<data..> (sync) [2019-07-12 16:14:45][bitwarden_rs::auth][ERROR] Unauthorized Error: No access token provided [2019-07-12 16:14:45][_][INFO] Outcome: Failure [2019-07-12 16:14:45][_][WARN] Responding with 401 Unauthorized catcher. [2019-07-12 16:14:45][_][INFO] Response succeeded. ```
OVERLORD commented 2026-02-04 19:42:17 +03:00
Author
Owner
Copy Link

@mprasil commented on GitHub (Jul 15, 2019):

Any proxy in front?

@mprasil commented on GitHub (Jul 15, 2019): Any proxy in front?
OVERLORD commented 2026-02-04 19:42:32 +03:00
Author
Owner
Copy Link

@gerroon commented on GitHub (Jul 15, 2019):

Hi

Yes forgot to mention, I am running it behind Apache proxy, using the proxy settings provided in the wiki.

@gerroon commented on GitHub (Jul 15, 2019): Hi Yes forgot to mention, I am running it behind Apache proxy, using the proxy settings provided in the wiki.
OVERLORD commented 2026-02-04 19:42:38 +03:00
Author
Owner
Copy Link

@mprasil commented on GitHub (Jul 15, 2019):

Can you see if anything relevant pops up in Apache logs? The above logs doesn't seem to be relevant which makes me think there is some Apache configuration blocking attachment requests.

@mprasil commented on GitHub (Jul 15, 2019): Can you see if anything relevant pops up in Apache logs? The above logs doesn't seem to be relevant which makes me think there is some Apache configuration blocking attachment requests.
OVERLORD commented 2026-02-04 19:42:55 +03:00
Author
Owner
Copy Link

@gerroon commented on GitHub (Jul 16, 2019):

Well those lines of the log is created right when I try to open an attachment.

I will take a look at the apache logs.

@gerroon commented on GitHub (Jul 16, 2019): Well those lines of the log is created right when I try to open an attachment. I will take a look at the apache logs.
OVERLORD commented 2026-02-04 19:43:12 +03:00
Author
Owner
Copy Link

@mprasil commented on GitHub (Jul 17, 2019):

Ah I've noticed the attachment URL is appended to the sync API call. This sounds like wrong configuration on apache side. Can you share your config?

@mprasil commented on GitHub (Jul 17, 2019): Ah I've noticed the attachment URL is appended to the sync API call. This sounds like wrong configuration on apache side. Can you share your config?
OVERLORD commented 2026-02-04 19:43:17 +03:00
Author
Owner
Copy Link

@gerroon commented on GitHub (Jul 17, 2019):


<VirtualHost *:443>
        RewriteEngine On
        RewriteCond %{HTTP:Upgrade} =websocket [NC]
        RewriteRule /notifications/hub(.*) ws://<SERVER>:3012/$1 [P,L]
        ProxyPass / http://127.0.0.1:4030/

        ProxyPreserveHost On
        ProxyRequests Off
        RequestHeader set X-Real-IP %{REMOTE_ADDR}s

</VirtualHost>
@gerroon commented on GitHub (Jul 17, 2019): ``` <VirtualHost *:443> RewriteEngine On RewriteCond %{HTTP:Upgrade} =websocket [NC] RewriteRule /notifications/hub(.*) ws://<SERVER>:3012/$1 [P,L] ProxyPass / http://127.0.0.1:4030/ ProxyPreserveHost On ProxyRequests Off RequestHeader set X-Real-IP %{REMOTE_ADDR}s </VirtualHost> ```
OVERLORD commented 2026-02-04 19:43:29 +03:00
Author
Owner
Copy Link

@mprasil commented on GitHub (Jul 18, 2019):

That part seems Okay, there must be some other configuration that's interfering with the requests. My main concern is this part:

/api/sync?excludeDomains=true/attachments/e2d7725b-d771-4e2e-9e55-97ccb0fe64b3/f5b823f0078a67c2b358

This seems to be concatenation of two request paths:

/api/sync?excludeDomains=true

This one is for synchronization and obviously requires login token. (which is why it is complaining about it's absence)

/attachments/e2d7725b-d771-4e2e-9e55-97ccb0fe64b3/f5b823f0078a67c2b358

Actual attachment download request as it should be. AFAIK this one does not require token. So it seems like your client app actually sends this request correctly, but something in between mangles the request and it is then hitting the wrong sync endpoint.

Hope that makes sense.

@mprasil commented on GitHub (Jul 18, 2019): That part seems Okay, there must be some other configuration that's interfering with the requests. My main concern is this part: ``` /api/sync?excludeDomains=true/attachments/e2d7725b-d771-4e2e-9e55-97ccb0fe64b3/f5b823f0078a67c2b358 ``` This seems to be concatenation of two request paths: ``` /api/sync?excludeDomains=true ``` This one is for synchronization and obviously requires login token. (which is why it is complaining about it's absence) ``` /attachments/e2d7725b-d771-4e2e-9e55-97ccb0fe64b3/f5b823f0078a67c2b358 ``` Actual attachment download request as it should be. AFAIK this one does not require token. So it seems like your client app actually sends this request correctly, but something in between mangles the request and it is then hitting the wrong `sync` endpoint. Hope that makes sense.
OVERLORD commented 2026-02-04 19:43:35 +03:00
Author
Owner
Copy Link

@gerroon commented on GitHub (Jul 18, 2019):

@mprasil sure it makes sense but it does not solve my issue :)

Are you guys able to download attachments in a similar setup?

@gerroon commented on GitHub (Jul 18, 2019): @mprasil sure it makes sense but it does not solve my issue :) Are you guys able to download attachments in a similar setup?
OVERLORD commented 2026-02-04 19:43:39 +03:00
Author
Owner
Copy Link

@mprasil commented on GitHub (Jul 19, 2019):

I don't use Apache, so unfortunately can't verify that. But the config you posted seems alright.

The reason the attachment download fails seems to be due to malformed request, so the only outstanding question is what causes this.

To rule out client issue, you can test with curl:

curl -v "http://yourserver/<attachment_path_from_above>"

And see the curl output and server logs. That might pinpoint the source of issues.

@mprasil commented on GitHub (Jul 19, 2019): I don't use Apache, so unfortunately can't verify that. But the config you posted seems alright. The reason the attachment download fails seems to be due to malformed request, so the only outstanding question is what causes this. To rule out client issue, you can test with curl: `curl -v "http://yourserver/<attachment_path_from_above>"` And see the curl output and server logs. That might pinpoint the source of issues.
OVERLORD commented 2026-02-04 19:43:49 +03:00
Author
Owner
Copy Link

@gerroon commented on GitHub (Jul 19, 2019):

@mprasil, thank you for the reply. I will try your recommendation.

@gerroon commented on GitHub (Jul 19, 2019): @mprasil, thank you for the reply. I will try your recommendation.
OVERLORD commented 2026-02-04 19:43:57 +03:00
Author
Owner
Copy Link

@mprasil commented on GitHub (Jul 27, 2019):

Any update? Is this resolved?

@mprasil commented on GitHub (Jul 27, 2019): Any update? Is this resolved?
OVERLORD commented 2026-02-04 19:44:02 +03:00
Author
Owner
Copy Link

@gerroon commented on GitHub (Aug 1, 2019):

@mprasil

It does not work. I am even connecting to it using the actual IP of local connection and I am getting the exact same problem.

I have no problem attaching a file to an item.

Does downloading attachments work for you?

Here is the error with direct IP connection (o the Docker container), there are couple new lines with more clarity.

[2019-07-31 23:58:05][rocket::rocket][INFO] GET /api/ciphers/6772a42a-ad76-4d0a-83fe-246b73c9c49f/attachment/attachments/6772a42a-ad76-4d0a-83fe-246b73c9c49f/d697287addd894d2e84c:
[2019-07-31 23:58:05][_][INFO] Matched: GET /<p..> [10] (web_files)
[2019-07-31 23:58:05][_][ERROR] Response was a non-`Responder` `Err`: Os { code: 2, kind: NotFound, message: "No such file or directory" }.
[2019-07-31 23:58:05][_][INFO] Outcome: Failure
[2019-07-31 23:58:05][_][WARN] Responding with 500 Internal Server Error catcher.
[2019-07-31 23:58:05][_][INFO] Response succeeded.

As far as I can tell the attachments are there.Maybe there is a typo in the code?

(persistent volume)
bitwarden/attachments/6772a42a-ad76-4d0a-83fe-246b73c9c49f

ls -alh

drwxr-xr-x 1 root root  120 Jul 31 18:54 .
drwxr-xr-x 1 root root  288 Jul 31 18:54 ..
-rw-r--r-- 1 root root  75K Jul 31 18:54 426f534e0d4dfa753143
-rw-r--r-- 1 root root 221K Jul 31 18:54 5dbdba5a85557aaf6ef9
-rw-r--r-- 1 root root 124K Jul 31 18:54 d697287addd894d2e84c
@gerroon commented on GitHub (Aug 1, 2019): @mprasil It does not work. I am even connecting to it using the actual IP of local connection and I am getting the exact same problem. I have no problem attaching a file to an item. Does downloading attachments work for you? Here is the error with direct IP connection (o the Docker container), there are couple new lines with more clarity. ``` [2019-07-31 23:58:05][rocket::rocket][INFO] GET /api/ciphers/6772a42a-ad76-4d0a-83fe-246b73c9c49f/attachment/attachments/6772a42a-ad76-4d0a-83fe-246b73c9c49f/d697287addd894d2e84c: [2019-07-31 23:58:05][_][INFO] Matched: GET /<p..> [10] (web_files) [2019-07-31 23:58:05][_][ERROR] Response was a non-`Responder` `Err`: Os { code: 2, kind: NotFound, message: "No such file or directory" }. [2019-07-31 23:58:05][_][INFO] Outcome: Failure [2019-07-31 23:58:05][_][WARN] Responding with 500 Internal Server Error catcher. [2019-07-31 23:58:05][_][INFO] Response succeeded. ``` As far as I can tell the attachments are there.Maybe there is a typo in the code? (persistent volume) `bitwarden/attachments/6772a42a-ad76-4d0a-83fe-246b73c9c49f` `ls -alh` ``` drwxr-xr-x 1 root root 120 Jul 31 18:54 . drwxr-xr-x 1 root root 288 Jul 31 18:54 .. -rw-r--r-- 1 root root 75K Jul 31 18:54 426f534e0d4dfa753143 -rw-r--r-- 1 root root 221K Jul 31 18:54 5dbdba5a85557aaf6ef9 -rw-r--r-- 1 root root 124K Jul 31 18:54 d697287addd894d2e84c ```
OVERLORD commented 2026-02-04 19:44:06 +03:00
Author
Owner
Copy Link

@gerroon commented on GitHub (Aug 1, 2019):

Also interesting, I upgraded the docker image from 2.10.1 to 2.11 and I am now getting a totally different and unhelpful log lines when clicked on an attachment. Again this is a direct connection to the Docker server.

2.10 was giving me 500, this one is givng me 401

[2019-08-01 00:13:35][rocket::rocket][INFO] GET /api/sync?excludeDomains=true/attachments/6772a42a-ad76-4d0a-83fe-246b73c9c49f/5dbdba5a85557aaf6ef9:
[2019-08-01 00:13:35][_][INFO] Matched: GET /api/sync?<data..> (sync)
[2019-08-01 00:13:35][bitwarden_rs::auth][ERROR] Unauthorized Error: No access token provided
[2019-08-01 00:13:35][_][INFO] Outcome: Failure
[2019-08-01 00:13:35][_][WARN] Responding with 401 Unauthorized catcher.
[2019-08-01 00:13:35][_][INFO] Response succeeded.

see the file attachments/6772a42a-ad76-4d0a-83fe-246b73c9c49f/5dbdba5a85557aaf6ef9 is there again

bitwarden/attachments/6772a42a-ad76-4d0a-83fe-246b73c9c49f# ls -alh

-rw-r--r-- 1 root root  75K Jul 31 18:54 426f534e0d4dfa753143
-rw-r--r-- 1 root root 221K Jul 31 18:54 5dbdba5a85557aaf6ef9
-rw-r--r-- 1 root root 124K Jul 31 18:54 d697287addd894d2e84c

This is how I run it

docker run -d --name bitwarden -v /media/DRIVE/bitwarden:/data/ -p 4080:80 -p 3012:3012 bitwardenrs/server:latest

@gerroon commented on GitHub (Aug 1, 2019): Also interesting, I upgraded the docker image from `2.10.1` to `2.11` and I am now getting a totally different and unhelpful log lines when clicked on an attachment. Again this is a direct connection to the Docker server. 2.10 was giving me 500, this one is givng me 401 ``` [2019-08-01 00:13:35][rocket::rocket][INFO] GET /api/sync?excludeDomains=true/attachments/6772a42a-ad76-4d0a-83fe-246b73c9c49f/5dbdba5a85557aaf6ef9: [2019-08-01 00:13:35][_][INFO] Matched: GET /api/sync?<data..> (sync) [2019-08-01 00:13:35][bitwarden_rs::auth][ERROR] Unauthorized Error: No access token provided [2019-08-01 00:13:35][_][INFO] Outcome: Failure [2019-08-01 00:13:35][_][WARN] Responding with 401 Unauthorized catcher. [2019-08-01 00:13:35][_][INFO] Response succeeded. ``` see the file `attachments/6772a42a-ad76-4d0a-83fe-246b73c9c49f/5dbdba5a85557aaf6ef9` is there again ``` bitwarden/attachments/6772a42a-ad76-4d0a-83fe-246b73c9c49f# ls -alh -rw-r--r-- 1 root root 75K Jul 31 18:54 426f534e0d4dfa753143 -rw-r--r-- 1 root root 221K Jul 31 18:54 5dbdba5a85557aaf6ef9 -rw-r--r-- 1 root root 124K Jul 31 18:54 d697287addd894d2e84c ``` This is how I run it `docker run -d --name bitwarden -v /media/DRIVE/bitwarden:/data/ -p 4080:80 -p 3012:3012 bitwardenrs/server:latest`
OVERLORD commented 2026-02-04 19:44:10 +03:00
Author
Owner
Copy Link

@mprasil commented on GitHub (Aug 1, 2019):

Have you also tried the latest image? I was testing with latest and with Vault and Firefox extension as a client and it worked fine in both cases for me - both uploading and downloading.

Did you try with curl?

curl -v "http://yourserver/attachments/6772a42a-ad76-4d0a-83fe-246b73c9c49f/5dbdba5a85557aaf6ef9"

I've used the attachment URL from your logs above, but if that attachment is gone, adapt the URL to some valid ID.

@mprasil commented on GitHub (Aug 1, 2019): Have you also tried the latest image? I was testing with `latest` and with Vault and Firefox extension as a client and it worked fine in both cases for me - both uploading and downloading. Did you try with curl? ```bash curl -v "http://yourserver/attachments/6772a42a-ad76-4d0a-83fe-246b73c9c49f/5dbdba5a85557aaf6ef9" ``` I've used the attachment URL from your logs above, but if that attachment is gone, adapt the URL to some valid ID.
OVERLORD commented 2026-02-04 19:44:22 +03:00
Author
Owner
Copy Link

@gerroon commented on GitHub (Aug 1, 2019):

This is what I get

https://bin.privacytools.io/?151dceae1a126917#7i7Wgpk1dzogng6eNHNemfutlD8rpv3lA5UBT5jLyaI=

@gerroon commented on GitHub (Aug 1, 2019): This is what I get https://bin.privacytools.io/?151dceae1a126917#7i7Wgpk1dzogng6eNHNemfutlD8rpv3lA5UBT5jLyaI=
OVERLORD commented 2026-02-04 19:44:28 +03:00
Author
Owner
Copy Link

@mprasil commented on GitHub (Aug 2, 2019):

Did you see corresponding request also in bitwarden_rs logs?

@mprasil commented on GitHub (Aug 2, 2019): Did you see corresponding request also in bitwarden_rs logs?
OVERLORD commented 2026-02-04 19:44:41 +03:00
Author
Owner
Copy Link

@mprasil commented on GitHub (Aug 15, 2019):

Any update @gerroon ?

@mprasil commented on GitHub (Aug 15, 2019): Any update @gerroon ?
OVERLORD commented 2026-02-04 19:44:50 +03:00
Author
Owner
Copy Link

@mprasil commented on GitHub (Aug 20, 2019):

I'm going to resolve this hoping that no response means the problem was resolved. Feel free to reopen if issue still persists.

@mprasil commented on GitHub (Aug 20, 2019): I'm going to resolve this hoping that no response means the problem was resolved. Feel free to reopen if issue still persists.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
SSO
Third party
better for forum
bug
bug
documentation
duplicate
enhancement
future Vault
future Vault
future Vault
good first issue
help wanted
low priority
notes
pull-request
Mirrored from GitHub Pull Request
 question
troubleshooting
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/vaultwarden#335
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?