Files not being stored or referenced in /upload directory.Potential Redis issue?

[zeluspudding]

I've followed the directions at https://github.com/timvisee/send-docker-compose to provision send.

I basically do this.

• Create a digital ocean droplet using the one click install docker image
• Run the following to open ports 80 and 443

sudo ufw allow 80
sudo ufw allow 443

• In my base directory (as root user) run git clone https://github.com/timvisee/send-docker-compose
• run cd send-docker-compose/
• Run cp .env.example .env
• Configure .env using nano .env
• Run docker-compose up

Everything looks good until I actually upload a file... this is when the loading bar freezes and I get these console errors:

If I take a look at the docker logs, I see this error about No such file or directory:

Here's the larger log context:

I've also seen a similar failure where the error log reports auth called without any password configured for the default user

The first error seems very similar to the one reported in issue Links Immediately Expire

send_1   | {"Timestamp":1611932387057000000,"Logger":"FirefoxSend","Type":"send.storage.Redis:","Severity":2,"Pid":1,"EnvVersion":"2.0","Fields":{"msg":"Retry time exhausted"}}

However, unlike in that case, I am only trying to use the default installation/not involving traefik. I am also not involving S3 or an external file store. Any idea what the matter may be?

[zeluspudding]

Ah, I just found the log for the ERR AUTH error;

I've troubleshot this for nearly the last 4 hours and am out of ideas as to where to supply these credentials or how to get the docker image to properly use the /uploads directory. Any help greatly appreciated :)

[zeluspudding]

Perhaps a recent commit add env for redis pwd and port has something to do with this?

[timvisee]

This likely has to do with permission errors in the upload directory that is mounted.

When you aren't using S3, it stores files in a local directory.

Have you tried setting different permissions on the mounted directory? Send runs as a special user inside the container for security reasons, which is why you have to give it explicit permission.

You can temporarily set the directory mode to 777 to see if it fixes the upload.

chmod -R 777 MY_DIR

When that works, write down the user and group ID the uploaded files have. Change the permission mode of the whole folder back, and make the noted user and group ID owner.

Does that help?

[timvisee]

I was a bit quick. After closer inspection, you might be right that the linked commit is causing issues.

I'm investigating this further now.

Would you mind to check the image tagged v3.4.6 in the mean time, which doesn't have this issue yet?

[timvisee]

Perhaps a recent commit add env for redis pwd and port has something to do with this?

It looks like you were right. The Redis client behaved differently than expected when an empty password is provided.

I've pushed a fix, which is part of v3.4.8. It should be available when this pipeline succeeds: https://gitlab.com/timvisee/send/-/pipelines/289468716

When the pipeline succeeded, you may pull the new image with docker-compose pull.

[zeluspudding]

I just gave it a go and am seeing the same issue as before.

I will give chmod -R 777 MY_DIR a try to see what comes of that

[zeluspudding]

I ran chmod -R 777 uploads and send now works!!

You mentioned having to revert this folder permission:

When that works, write down the user and group ID the uploaded files have. Change the permission mode of the whole folder back, and make the noted user and group ID owner.

How do I do that?

And one last question - the original send documentation recommended not to use docker-compose in production:

Is this also true of this project? If so, how do we configure this docker container for production use (I can open a new issue if merited)? Thanks!

[timvisee]

When that works, write down the user and group ID the uploaded files have. Change the permission mode of the whole folder back, and make the noted user and group ID owner.

How do I do that?

Note the user and group ID. Then change the directory permissions and change the file mode to read/write for the user/group you've set.

chown -R USERID:GROUPID UPLOADS_DIR
chmod -R 664 UPLOADS_DIR

You could keep it the way it is, without running these commands (after setting its mode to 777) if you don't care too much about local file permissions.

Is this also true of this project? If so, how do we configure this docker container for production use (I can open a new issue if merited)? Thanks!

It should be fine, especially with restart: always set for each container. But it might get in the way if you'd like to host it on another platform, for better redundancy/scaling. I'm not an expert on this though. Note that I do host https://send.vis.ee/ with docker-compose just fine.

[zeluspudding]

Sweeeeeet! Thank you Tim, you've been very helpful to me and the larger community in need of this application. Sounds like I'm all set.

I'd like to tip you and have a few options - I can do so via BAT once Brave rolls out their native wallet (because I'm not yet verified via Uphold). Or I can do so now via some other contribution page. Just let me know, thanks!

[timvisee]

Sweeeeeet! Thank you Tim, you've been very helpful to me and the larger community in need of this application. Sounds like I'm all set.

Fantastic! Happy to see you got it working.

I'd like to tip you and have a few options - I can do so via BAT once Brave rolls out their native wallet (because I'm not yet verified via Uphold). Or I can do so now via some other contribution page. Just let me know, thanks!

That's awesome. Please see the following page. Much appreciated!
https://timvisee.com/donate/

[zeluspudding]

Sponsored! Thanks again :)

[Antoine2tt]

Hello !

I'm sorry to bother you, but i'm having the same issue.

I did what @timvisee said

Set upload dir to 777, i did ls -l to see the GID/UID (which was 10001/10001 in my case)

Then i did :

chown -R 10001:10001 uploads/
chmod 664 uploads/

But i still have the same issue. File won't upload...

Hope that someone can help me.

Thanks !

[timvisee]

@Antoine2tt Do you see anything of interests in the logs?

docker-compose logs

# or
docker logs

That might help to pinpoint the issue, in case it isn't a permission issue.