live4soccer7

Anyone get this error when updating? I haven't updated in probably a few years, until now. started connecting [20200528-11:17:41] [INFO ] lib_mod_log_peer: xrdp_pid=144 connected to X11rdp_pid=50 X11rdp_uid=99 X11rdp_gid=100 client_ip=127.0.0.1 client_port=35522 connected ok [20200528-11:17:41] [DEBUG] xrdp_mm_connect_chansrv: chansrvconnect successful [20200528-11:17:41] [DEBUG] returnvalue from xrdp_mm_connect 0 lib_mod_process_message: type 2 len 0 lib_send_client_info: xrdp_wm_login_mode_changed: login_mode is 3 [20200528-11:17:41] [INFO ] The following channel is allowed: cliprdr (0) [20200528-11:17:41] [INFO ] The following channel is allowed: rdpsnd (1) [20200528-11:17:41] [INFO ] The following channel is allowed: rdpdr (2) [20200528-11:17:41] [DEBUG] The allow channel list now initialized for this session [20200528-11:17:47] [INFO ] An established connection closed to endpoint: 127.0.0.1:35522 - socket: 8 xrdp_mcs_disconnect - socket closed [20200528-11:17:47] [DEBUG] xrdp_mm_module_cleanup [20200528-11:17:47] [INFO ] An established connection closed to endpoint: 109.112.47.46:12148 - socket: 11 [20200528-11:17:47] [INFO ] An established connection closed to endpoint: 109.112.47.46:12148 - socket: 12 xrdp:xrdp_encoder [1551967640]: xrdp_encoder_delete: [20200528-11:17:47] [ERROR] Listening socket is in wrong state we terminate listener

Try port 443. I know spaceinvader says to change it, however that is the only way I could get mine to work as well. It was weird as it didn't make sense to me because I changed the port in the conf files, but it was like it wouldn't listen to what I was setting. It was like there was another setting somewhere defining which port nextcloud was listening on. I also left the bitwarden on the default port too. I was able to get both working.

My question to this would be, would it then use the internet for viewing etc... or would it work over the local LAN. Right now it appears to be utilizing the internet and not the local LAN when accessing it from a local machine.

Yes, I always hit save after inputting new settings and then sending a test email after it has saved. What did you do to fix the problem? Are you using port 465 or 587 and do you have TLS checked or not?

I'm having some issues setting up smtp on bitwardenrs. I have a dedicated gmail account that I use for another service. I have enabled 2fa and created an app key/password and utilized that within bitwarden, just as I have with my other application (node-red). No matter what I try, it will not send a test email. I thought maybe it was gmail, so I went ahead and created a yahoo account and the result was the same. I just installed the latest version of bitwardenrs for the first time a couple weeks ago and have finished setting it up now. Here is the error I'm receiving. Has anyone else had this experience and if so, what did you do to resolve it? I have tried 587 TLS and 465 without TLS and every combination in between. [CAUSE] Io( Os { code: 11, kind: WouldBlock, message: "Resource temporarily unavailable", }, ) [2020-04-30 09:05:48][response][INFO] POST /admin/test/smtp (test_smtp) => 400 Bad Request [2020-04-30 09:05:53][request][INFO] POST /admin/config/ [2020-04-30 09:05:53][response][INFO] POST /admin/config (post_config) => 200 OK [2020-04-30 09:05:54][request][INFO] GET /admin [2020-04-30 09:05:54][response][INFO] GET /admin (admin_page) => 200 OK [2020-04-30 09:06:00][request][INFO] POST /admin/test/smtp/ [2020-04-30 09:06:01][lettre::smtp][INFO] connection established to 188.125.73.26:465 [2020-04-30 09:06:02][error][ERROR] LetreErr. [CAUSE] Permanent( Response { code: Code { severity: PermanentNegativeCompletion, category: Unspecified3, detail: Five, }, message: [ "5.7.0 (#AUTH005) Too many bad auth attempts.", ], }, ) [2020-04-30 09:06:02][response][INFO] POST /admin/test/smtp (test_smtp) => 400 Bad Request

^ definitely a good question. I have another quick question. Once SSL/Letsencrypt is setup and working, should I be able to access the docker at the local address:port (192.168.1.110:444) or will it only be accessible via the URL/Domain that was setup?

I'm not sure what to say. I put everything back to the way it downloaded (unchanged) with the exception of commenting out the subfolder aspect in the default conf file within letsencrypt. At that point everything worked as expected and I have also set up to other dockers on subdomains without issues and without having to edit any files other than changing servername to match my subdomain.

One thing to note, I did change the ports back to 443. I wanted to change back to 444 or something different, however when I did this by changing it in the nextcloud docker container (444), the nextcloud config.php, and the nextcloud.subdomain.conf, I was presented with a 502 bad gateway. Is there another file that would need adjusted that I'm simply not seeing?

I got it! It just hit me. It seemed like the subdomain.conf was not getting read, so I though well maybe the subfolder inclusion in the letsencrypt default conf was actually over-riding or taking priority/preference over the subdomain.conf inclusion. It came with both uncommented. I commented out the subfolder and voila. # enable subfolder method reverse proxy confs #include /config/nginx/proxy-confs/*.subfolder.conf; Again, this is in: letsencrypt/nginx/site-confs/default I suppose it is possible that I uncommented this somehow without realizing it, but I'm pretty sure it came with both uncommented.

I just changed the container port to 443, adjusted nextcloud.subdomain.conf to 443 and same with nextcloud's config.php. The result was the same. It is simply loading the letsencrypt index.html, so nexcloud's proxy is not getting passed. In the readme within proxy-confs for letsencrypt, the following lines standout to me. Is there really nothing to do within the default site config? ### Configure your default site config Make sure that your default site config contains the following lines in the appropriate spots as seen in the default version: 1) For subfolder methods: `include /config/nginx/proxy-confs/*.subfolder.conf;` 2) For subdomain methods: `include /config/nginx/proxy-confs/*.subdomain.conf;`

Are you referring to the container port? I have changed the port that the nexcloud container uses to 444 (why my subdomain.conf and config.php reflect this). You're saying to leave it at 443 and then adjust the subdomain.conf and config.php back to 443 for the container port? I still don't think this would be the issue because I tried setup the subdomain for sonarr with lets encrypt as well and my results are the exact same as with nextcloud. Yes, I have created a custom network that nextcloud and letsencrypt are on. I really appreciate everyone's time on this. I have been pulling my hair out over this for the last week and a half.

It is commented out, so essentially no change. You can see where it is commented out. Yes, I restarted everything. Otherwise everything is 100% stock in this file. I commented out my addition, so it has no effect.

Thank you very much. I have definitely expended many many many hours getting this setup, so it isn't a lack of effort. I am no expert either. I think that something has changed in the latest versions released by LSIO as I'm seeing my stock files included are just a little different than others' files on the thread. Hopefully, with your configs I may be able to piece something together.

Are you referring to the router's WAN IP that would be provided in a DDNS service such as duckdns? If so, that is correct. If it weren't then it wouldn't load back to the server from an external source and load the index.html page that is shown. I'm confident that is setup properly. I'm thinking that it would be something in the default.conf file within let's encrypt. I am attaching it now. ## Version 2020/03/05 - Changelog: https://github.com/linuxserver/docker-letsencrypt/commits/master/root/defaults/default # redirect all traffic to https server { listen 80 default_server; listen [::]:80 default_server; server_name _; return 301 https://$host$request_uri; } # main server block server { listen 443 ssl http2 default_server; listen [::]:443 ssl http2 default_server; root /config/www; index index.html index.htm index.php; server_name _; # enable subfolder method reverse proxy confs include /config/nginx/proxy-confs/*.subfolder.conf; # enable subdomain method reverse proxy confs #include /config/nginx/proxy-confs/*.subdomain.conf; # all ssl related config moved to ssl.conf include /config/nginx/ssl.conf; # enable for ldap auth #include /config/nginx/ldap.conf; client_max_body_size 0; location / { try_files $uri $uri/ /index.html /index.php?$args =404; } location ~ \.php$ { fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include /etc/nginx/fastcgi_params; } # sample reverse proxy config for password protected couchpotato running at IP 192.168.1.50 port 5050 with base url "cp" # notice this is within the same server block as the base # don't forget to generate the .htpasswd file as described on docker hub # location ^~ /cp { # auth_basic "Restricted"; # auth_basic_user_file /config/nginx/.htpasswd; # include /config/nginx/proxy.conf; # proxy_pass http://192.168.1.50:5050/cp; # } } # sample reverse proxy config without url base, but as a subdomain "cp", ip and port same as above # notice this is a new server block, you need a new server block for each subdomain #server { # listen 443 ssl http2; # listen [::]:443 ssl http2; # # root /config/www; # index index.html index.htm index.php; # # server_name cp.*; # # include /config/nginx/ssl.conf; # # client_max_body_size 0; # # location / { # auth_basic "Restricted"; # auth_basic_user_file /config/nginx/.htpasswd; # include /config/nginx/proxy.conf; # proxy_pass http://192.168.1.50:5050; # } #} # sample reverse proxy config for "heimdall" via subdomain, with ldap authentication # ldap-auth container has to be running and the /config/nginx/ldap.conf file should be filled with ldap info # notice this is a new server block, you need a new server block for each subdomain #server { # listen 443 ssl http2; # listen [::]:443 ssl http2; # # root /config/www; # index index.html index.htm index.php; # # server_name heimdall.*; # # include /config/nginx/ssl.conf; # # include /config/nginx/ldap.conf; # # client_max_body_size 0; # # location / { # # the next two lines will enable ldap auth along with the included ldap.conf in the server block # auth_request /auth; # error_page 401 =200 /login; # # include /config/nginx/proxy.conf; # resolver 127.0.0.11 valid=30s; # set $upstream_app heimdall; # set $upstream_port 443; # set $upstream_proto https; # proxy_pass $upstream_proto://$upstream_app:$upstream_port; # } #} # enable subdomain method reverse proxy confs include /config/nginx/proxy-confs/*.subdomain.conf; # enable proxy cache for auth proxy_cache_path cache/ keys_zone=auth_cache:10m; This is the part that is the most interesting and seems like the culprit at this point. # enable subdomain method reverse proxy confs include /config/nginx/proxy-confs/*.subdomain.conf; as you can see, I have added it in toward the beginning of this file, but it creates a can not connect to server error when I do this (typical message seen within a browser).

In my opinion it seems that the subdomain.conf isn't even getting read yet by letsencrypt. It it were and the subdomain.conf wasn't setup properly then I would think there simply would be a gateway error and not the default letsencyrpt index.html page. It simply seems that letsencrypt is not being told to read the subdomain.conf and therefore not pointing to the container location where that container's file would then be served from by the webserver.