congrats!
Thank you Morlan, and thank you for your GREAT support in helping me to solve the problem!!
congrats!
Thank you Morlan, and thank you for your GREAT support in helping me to solve the problem!!
FOUND IT!!!
the firewall on my router disabled by default the incoming access on 443 (even if there was written: "When the security level is set to "High", access to the following services is allowed: Telnet, FTP, HTTP, HTTPS, DNS, IMAP, POP3, SMTP and IPv6 Ping"
So i created a rule to accept incoming connections on that port and now it works!!!!
This looks fine. Is the router maybe running some other service which might also use port 443? Try forwarding another external port to your servers 450 port and see if it reaches the standard "welcome to our server" page
YES, it works on 444 port!
So, how to detect the service which is using 443?
If I telned my domain on port 80 i get a blank screen (which should mean successful connection), but on port 443 I get "Impossible to open a connection with host".
It do no work, but I think I have to edit the 'default' configuration file... where could i find it? I did not mount any volume in the container...
It's like the container CAN'T be reached from outside.
No, both access.log and errors.log won't be updated after a failed access temptative.
Yes, everything went smooth.
But things are getting very interesting here:
I stopped letsencrypt container and fired up a pure nginx container with the following instructions:
---
version: "2.1"
services:
nginx:
image: linuxserver/nginx
container_name: nginx
environment:
- PUID=998
- PGID=100
- TZ=Europe/Rome
ports:
- 450:443
- 90:80
restart: unless-stopped
Then I tried to access it from different browsers:
- Chrome: no luck
- Chrome in private mode: SUCCESS!!!!!
- Edge: SUCCESS!!!!
- Internet Explorer: no luck
So, what's happening here??
On Chrome side, I probably added an extension which is blocking or controlling the ports...
Still, I cannot figure out why letsencrypt is still failing...
Moreover, command ss -tulwn gives the following result:
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
tcp LISTEN 0 4096 *:90 *:*
tcp LISTEN 0 4096 *:450 *:*
Hi Morlan...
Yes, I'm afraid the port is open.
After some experimenting i came up with this - still not working - configuration, using ports 450 and 81 (which I translated in the router configuration):
---
version: "2.1"
services:
letsencrypt:
image: linuxserver/letsencrypt
container_name: letsencrypt
cap_add:
- NET_ADMIN
environment:
- PUID=998
- PGID=100
- TZ=Europe/Rome
- URL=duckdns.org
- SUBDOMAINS=mysubdomain
- VALIDATION=http
- EMAIL=mymail
- DHLEVEL=2048 #optional
- ONLY_SUBDOMAINS=true #optional
- EXTRA_DOMAINS= #optional
- STAGING=false #optional
volumes:
- /srv/dev-disk-by-label-DOCUMENTS/LetsEncrypt:/config
ports:
- 450:443
- 90:80 #optional
restart: unless-stopped
I also created another bridged network in docker, but no luck again.
It's like being firewalled, but no firewall rule is set in OMV.
It is strange, everything should work, but it does not.
Hi everybody,
have some problem here, hope that someone help me.
I installed LetsEncrypt with docker-compose on a freshly installed OMV5, virtualized under Proxmox.
Everything went fine, except for a final message:
nginx: [alert] detected a LuaJIT version which is not OpenResty's; many optimizations will be disabled and performance will be compromised (see https://github.com/openresty/luajit2 for OpenResty's LuaJIT or, even better, consider using the OpenResty releases from https://openresty.org/en/download.html)
but, AFAIK, there should be no problem.
Well, the situation on LAN side is the following:
- if i visit my LOCAL OMV address via http, I reach OMV web admin page
- if i visit my LOCAL OMV address via HTTPS, I reach the nginx default web page:
Welcome to our server
The website is currently being setup under this address.
For help and support, please contact: me@example.com
The situation on the WEB site is bad:
- if I visit my remote OMV address via http, I reach OMV web admin page (if port 80 is forwarded)
- if I visit my remote OMV address via HTTPS, (port 443 either open or closed) I get a frustrating ERR_CONNECTION_TIMED_OUT.
Do you have any idea of what could be wrong?
Here my stack configuration:
---
version: "2.1"
services:
letsencrypt:
image: linuxserver/letsencrypt
container_name: letsencrypt
cap_add:
- NET_ADMIN
environment:
- PUID=998
- PGID=100
- TZ=Europe/Rome
- URL= (the url of my OMV, as subdomain.duckdns.org)
- VALIDATION=duckdns
- DUCKDNSTOKEN=(my token)
- EMAIL=(my email)
volumes:
- /srv/dev-disk-by-label-DOCUMENTS/LetsEncrypt:/config
ports:
- 443:443
restart: unless-stopped
Hi,
can you share please the code you used for transmission? Thank you!
Hi everybody,
I have a problem: I want to remotely access my transmission webpanel via SSL (I installed a Letsencrypt certificate for my OMV, which I access via a no-ip domain).
Under Openmediavault 2 the transmission admin panel could be accessed as a child page of the OMV admin panel itself, so there was no problem, but under OMV 3 it will open an external link which will not be accessible as a secure page.
I digged a bit and found that nginx could be configured to do the trick, but I have no idea of how to do it: tried to follow some procedure, but with no luck. I am not new to linux, but this matter is a bit out of reach for me.
Could anyone help me please? Thank you very very much!