Change image folder to symlinked folder

From the link above, I can see that images and attachments are stored in deeper shared folder in Discourse installation, not inside the docker. Given that I would like to use a symlinked image folder from my second storage, which I NFS-mount to another servers. And, on a secondary server, I would like to run Discourse’s docker container, as a means of load-balancing / failover…, and woule like to use the same image folder from NFS-mount. I already have DB from another network server, just in case.

I’ve just tested the setting, but the result isn’t good. I copied all image files from /var/discourse/shared/standalone/uploads to /var/www/image/uploads
Then,

  • Created symlinks to NFS mounted image folder
  • chmod & chown w/ www-data:www-data and 755 for the /uploads folders

I can see images on the primary server where image folder is natively mounted, but not the case on the NFS-mounted secondary server. Image’s are missing with size container.

Besides, even on the primary server, I can see, but cannot download the image anymore.

I guess it is due to file permission. Wonder what’s the ideal setting.

Not sure if it is vanilla or due to dozens of rebuild, but images in the default folder are 755/644 (folder/file) and main_id:www-data in my server. I also copied the same strategy, but didn’t work. Could be symlink or NFS specific issue, but I cannot track anymore.

What if you used a CDN for the images instead?

@NateDhaliwal thank you for the idea.

I stopped using CDN services like S3 long time ago. I only use cloudflare, but that doesn’t really store images.

Correct me if I am wrong, but I think you are referring localized CDN like simple Nginx domain mapping, and use Discourse’s CDN extension like Enable a CDN for your Discourse - Documentation / Self-Hosting - Discourse Meta

If there isn’t any other solution, I will do so. Thought file permissions are easier solution.

1 Like

Rather than a symlink, change the docker mount to point to your nfs mount.

But getting permissions inside the container, outside the container, and on the remote nfs server on sync can certainly be tricky.

1 Like

That was my initial attempt. Inside the docker, I found the file system for mine was kinda messed up that I found earlier. It was nested /uploads/uploads/uploads before /default/ was seen. Not sure what really happened, but I copied all files from the inside to my image mount, and added the mount folder as a volume.

Here, the situation was not that different from symlink. File permissions indeed create the same problem. After understanding that files are actually stored outside of Docker container, I thought symlink can be much easier solution.

For both, I am almost sure that it is file permission, but custom CDN just by Nginx server block sounds much more simpler solution that docker volume, as long as symlink doesnt work.

I’m fairly certain that no good can from using symlinks. One issue is that it’s hard to have the symlink be the same inside and outside the container, and I’m guessing that your nested uploads issue is related to that. I’ve seen it recommended not to use symlinks and I think this is why.

Does Discourse support custom CNAME based CDN? I remember seeing S3 configuration in admin and meta posting for Fastly, but cannot quite remember custom CDN configuration.

Found the posting. Guess I need to set up a self-hosted version of S3 compatible CDN. Mere Nginx image server isnt enough.