Uploaded images not found

[tanc]

I wanted to modify the email environment variables passed into the docker images so I issued a docker-compose down and docker-compose up -d. Once it came up successfully I noticed the image I had uploaded for one site won't load. Are these stored somewhere in the docker image rather than in the database or a non-volatile volume or filesystem?

The server issues a 404 for that image:

https://meli.jampony.net/api/v1/sites/883e900d-eae1-42f2-9afa-3c84a270c6da/logo?id=bd9c3c27-f083-4aaa-ade9-1d6be2c17dca

Resulting in a broken image link and the alt text "bubble" being shown:

Might also be worth changing the alt text to an empty string to indicate the image is purely decorative.

[gempain]

Images are stored in MELI_STORAGE_DIR which defaults to /files. You should map this Docker volume. If you had not mapped it, you will lose those images when restarting the docker image. I just noticed our docs is missing this in the installation section. I'll update it right away.

[tanc]

After mounting a local directory into the container (and before doing this) I can't delete or upload a new logo. If I try to delete the existing (broken) image I get a 500 error and this message:

Could not remove logo: Error: Request failed with status code 500

Trying to upload a new one also results in a similar 500 error with:

Could not upload logo: Error: Request failed with status code 500

[gempain]

I see the issue. It's because we're trying to delete the logo while it doesn't exist. Sorry for the inconvenience. Will com up with a fix.

[tanc]

No problem and thanks as always for your quick response!

[meli-release-bot]

🎉 This issue has been resolved in version 1.0.0-beta.23 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[tanc]

Thanks! Although for some reason I can't upload images on this new release. Deleting the broken image worked fine though. Uploading throws a 500 error.

I've got a mount in my docker-compose file:

 volumes:
      - /meli/sites:/sites
      - /meli/caddy/data:/data
      - /meli/caddy/config:/config
      - /meli/files:/files

I can touch a file in /meli/files and confirm it is in /files in the meli container.

Do want a new issue for this?

[gempain]

Are you sure you're using the latest version ? I just tried on our environment and it seems to work fine. Did you docker-compose pull before docker-compose up -d ?

[tanc]

I did yes, but I was on the getmeli/meli:next tag. I swapped to getmeli/meli:beta as it seems slightly newer and brought the containers up but I'm still seeing the same problem, 500 error when uploading image.

[tanc]

Meli is showing 1.0.0-beta.23 in the bottom right corner:

{
  "ui": {
    "version": "1.0.0-beta.13",
    "commitHash": "2021-05-21T12:41:58.366Z",
    "buildDate": "2021-05-21T12:41:58.366Z"
  },
  "api": {
    "version": "1.0.0-beta.23",
    "buildDate": "2021-05-21T12:41:44.941Z",
    "commitHash": "970e1f4d5fda64545a95b36028f11c35be90bf7a"
  }
}

I've tried making the /files directory permissions 777 inside the container to eliminate any potential permissions problems but that didn't help.

[tanc]

I just disabled the files volume mount and re-upped the containers and the uploading of images works. So something isn't good with my mount

[tanc]

The docker logs show this when trying to upload a file with a volume mount:

Error: EXDEV: cross-device link not permitted, rename '/tmp/f0ed6fec087fa9b0ebb98f661d77dd7c' -> '/files/1e5e38c2-dd69-4c8a-a054-8e0c8cf3cb1e'

[tanc]

Looks like a limit of rename, suggestions I've read are to copy the file into place first and then delete the version in /tmp

[gempain]

Ohhhh yes, I see, we've had this problem before for uploading sites and fixed it by copying. It's a problem related to how Docker works. We're first uploading the image into a temporary directory which isn't mapped, and then moving it to /files and that causes the issue.

[gempain]

@tanc this was an easy fix, sorry for the delay 😄 I'll release on beta soon.

[gempain]

@tanc this should be fixed in beta 24. I'll close, but we can reopen if needed.