# שגיאה בבנייה מחדש באמצעות minio כאחסון אובייקטים **URL:** \ **Category:** Product Support\ **Created:** [1 בספטמבר,‏ 2022,‏ 1:01am UTC](https://meta.discourse.org/t/error-in-rebuilding-using-minio-as-object-store/237776 "2022-09-01T01:01:48Z")\ **Posts on this page:** 1\ **Showing post:** 7
**Author:** ![teward](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/teward/32/148702_2.png) [@teward](https://meta.discourse.org/u/teward)\ **Post date:** [1 בספטמבר,‏ 2022,‏ 3:51pm UTC](https://meta.discourse.org/t/error-in-rebuilding-using-minio-as-object-store/237776/7 "2022-09-01T15:51:05Z")
> [@ShaoJie](#): > > I use Nginx proxy manager to forward [minio.example.com](http://minio.example.com) to port 9001 and [s3.example.com](http://s3.example.com) and [bucket-name.example.com](http://bucket-name.example.com) to port 9000 Forward what ports? 80/443 so http/https works? That’s all it needs, you should NEVER have to configure port 9000 on a separate port. The separate bucket will have the same endpoint as [s3.example.com](http://s3.example.com) - it’s not something separate, so you’re doing THAT configuration wrong. Don’t forget also that in MinIO speak, if you’re using path authentication you would end up with `s3.example.com/BUCKETNAME` or with DNS authentication like you should use `BUCKET.s3.example.com` for the URL endpoints that you need to accept on the nginx side and forward to the internal port 9000. You don’t need to configure that on your end though, that needs to be configured on the MinIO side. The MinIO client supports both `path` and `dns` style setup. To my knowledge, Discourse uses a URL based mechanism for bucket identification, not path style setups (feel free to correct me Discourse devs). Therefore the ‘default’ behavior you’re configuring is incorrect. Now, my MinIO is not dockerized, but to be compliant here with Discourse, you need to use DNS style pathing, i.e. you need to add in the environment variable of `MINIO_DOMAIN=BASEDOMAINHERE` so that DNS style pathing that DIscourse wants to use _works_. In your example it would be `MINIO_DOMAIN=s3.example.com` and then your NGINX would need to be configured to pass the Host header to the backend on port 9000 or wherever the base non-console server components run. You then need to make sure that NGINX accepts for `*.s3.example.com` and forwards it properly to the MinIO container. This is part of MinIO Federation setup, but for single-node instances with multiple bucket names on a base URL you need to make sure it’s properly configured anyways if you want it to work with Discourse. Unfortunately, though, this is where you have to start delving into the MinIO configurations. And one of the requisites I specify in the document is that you have a fully functional properly configured MinIO instance which is _beyond_ the scope of Discourse’s site. I believe that your MinIO is not properly configured for DNS style bucket resolution like AWS S3 does (`bucket.s3.example.com` for instance) and as such does not function. Note that I run the Discourse instance for the Lubuntu Project ([lubuntu.me](http://lubuntu.me)) (a variant of Ubuntu that uses LXQt) using a MinIO with **DNS style bucket URL resolution** in order to make it work properly with Discourse, otherwise a request for `BUCKET.basedomain.example.com` would fail. Fun fact, I even state you need your MinIO properly configured for DNS style paths, if you did not include the `MINIO_DOMAIN` during setup of MinIO it won’t do DNS style paths. Which it needs here for Discourse, as per item 3 in my caveats section I wrote: > [@MinIO Storage Server - Caveats - #3](#): > > You have DNS configuration properly set up for MinIO so that bucket subdomains properly resolve to the MinIO server and the MinIO server is configured with a base domain (in this case, `minio.example.com`) --- _[View the full topic](https://meta.discourse.org/t/error-in-rebuilding-using-minio-as-object-store/237776)._