So I ran into the "VMs cannot see host" as I could not map a network share in Windows Server VM.
I found a video online that got me to create a bridge and I was able to then map a drive in the Windows VM. Video here: https://www.youtube.com/watch?v=7clQw132w58
It was very helpful. Now I'm onto my next configuration to get my Let's Encrypt setup. But I believe something just isn't configured correctly. I've setup Let's Encrypt to get a cert for a domain, lets say truenas.mydomain.com, which was created and is available. I changed TrueNAS to use that cert as default. I rebooted the server for good measure.
Now, under network settings the TrueNAS primary IP is .159 and the bridge is .60
I'm operating the server on my own home network for now (eventually server will live in a datacenter and have a public IP). So I'm manually editing my hosts file to point the .159 IP to the domain/cert (truenas.mydomain.com) that I have setup in TrueNAS. I'm able to get my browser to goto truenas.mydomain.com, the web login works. All is well it seems.
Now I have the MinIO app installed as well. When I open the web portal via the button on the app, it opens to .159 (not truenas.mydomain.com) and works. But if manually change the address in the browser to truenas.mydomain.com with HTTPS for the MinIO console, I get a SSL_ERROR_RX_RECORD_TOO_LONG error in Firefox and Chrome says ERR_SSL_PROTOCOL_ERROR. MinIO is not configured correctly it seems to use the server cert?
This question/post is kinda all over the place (I apologize), so I'll sum up what I'm trying to achieve:
1) Have a bridge (or some other config) that allows my VMs to access the TrueNAS host storage pool/shares
2) Configured SSL certificate correctly on the server (I think I have this set properly)
3) Have any apps, particularly MinIO in this instance, be able to respond on the SSL certificate domain properly (will need this for the public MinIO API for object upload/downloads)
4) For the bridge configuration, I had to bind it to an available interface. Is that interface basically un-usable now by anything else?
Thanks,
Scott
I found a video online that got me to create a bridge and I was able to then map a drive in the Windows VM. Video here: https://www.youtube.com/watch?v=7clQw132w58
It was very helpful. Now I'm onto my next configuration to get my Let's Encrypt setup. But I believe something just isn't configured correctly. I've setup Let's Encrypt to get a cert for a domain, lets say truenas.mydomain.com, which was created and is available. I changed TrueNAS to use that cert as default. I rebooted the server for good measure.
Now, under network settings the TrueNAS primary IP is .159 and the bridge is .60
I'm operating the server on my own home network for now (eventually server will live in a datacenter and have a public IP). So I'm manually editing my hosts file to point the .159 IP to the domain/cert (truenas.mydomain.com) that I have setup in TrueNAS. I'm able to get my browser to goto truenas.mydomain.com, the web login works. All is well it seems.
Now I have the MinIO app installed as well. When I open the web portal via the button on the app, it opens to .159 (not truenas.mydomain.com) and works. But if manually change the address in the browser to truenas.mydomain.com with HTTPS for the MinIO console, I get a SSL_ERROR_RX_RECORD_TOO_LONG error in Firefox and Chrome says ERR_SSL_PROTOCOL_ERROR. MinIO is not configured correctly it seems to use the server cert?
This question/post is kinda all over the place (I apologize), so I'll sum up what I'm trying to achieve:
1) Have a bridge (or some other config) that allows my VMs to access the TrueNAS host storage pool/shares
2) Configured SSL certificate correctly on the server (I think I have this set properly)
3) Have any apps, particularly MinIO in this instance, be able to respond on the SSL certificate domain properly (will need this for the public MinIO API for object upload/downloads)
4) For the bridge configuration, I had to bind it to an available interface. Is that interface basically un-usable now by anything else?
Thanks,
Scott