timvisee / send

:mailbox_with_mail: Simple, private file sharing. Mirror of https://gitlab.com/timvisee/send

Home Page:https://send.vis.ee

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Download URL accessible but files won't download.

azza13b opened this issue · comments

I have a strange issue, where the download URL works. EG. I can see the Send-Archive.zip on the website.
But when I hit download nothing happens.

I installed ffsend on my linux box to see if I could download via command line, but again was unsuccessful.

ffsend error:

error: failed to download the requested file
caused by: couldn't use the target file at '/var/lib/snapd/void/Send-Archive.zip'

Anyone got any tips?

image

I have been doing some testing and I feel like the links stop working if I do a dock-compose up and down?

redis:
container_name: redis
image: 'redis:alpine'
restart: always
volumes:
- send-redis:/data

send:
image: 'registry.gitlab.com/timvisee/send:latest'
container_name: send
restart: always
ports:
- '1234:1234'
volumes:
- ./send/uploads:/uploads
environment:
- VIRTUAL_HOST=localhost
- VIRTUAL_PORT=1234
- DHPARAM_GENERATION=false
- LETSENCRYPT_HOST=localhost
- LETSENCRYPT_EMAIL=admin@
- NODE_ENV=production
- BASE_URL=https://send.
- PORT=1234
- REDIS_HOST=redis
- CUSTOM_FOOTER_TEXT=
- UI_COLOR_PRIMARY=#d41b22
- UI_COLOR_ACCENT=#af1f24
- CUSTOM_DESCRIPTION=Securely share your files with end-to-end encryption.
- CUSTOM_TITLE=
- SEND_FOOTER_SOURCE_URL=
- SEND_FOOTER_CLI_URL=
- EXPIRE_TIMES_SECONDS=2592000,5184000
- DOWNLOAD_COUNTS=50,70
- DEFAULT_DOWNLOADS=50
- MAX_EXPIRE_SECONDS=5184000
- DEFAULT_EXPIRE_SECONDS=2592000

volumes:
send-redis:

My proxy is in another container could that be th eissue?

  • LETSENCRYPT_HOST=localhost?

Are you sure Send properly connects to the Redis instance? If there's problems there files will be lost when restarting the container.

Inspecting the logs may show valuable information on this.

Thank you for the swift response! I will have to buy you a coffee.

Reviewing the send container logs, no errors were thrown. Initially, the redis container reported a memory overcommit issue, but after adjusting the host parameters, this warning has ceased. Network connectivity tests, including the nc command from the send container to the redis container on port 6379 and pinging between the containers, were successful.

I’ve also modified the docker-compose.yaml to establish a network linking the send, redis, and nginx-proxy-manager containers.

After the above, I did a quick test and the download links remain non-functional post-restart of the docker containers.

Where would you go looking next? Should I set a configuration file for the redis container? Is there another direction you would suggest?