buzzra Posted February 1, 2019 Share Posted February 1, 2019 I'm having a strange problem with this docker. I finally got the time to install it, and everything seemed to go fine. I left all the settings default, since there were no conflicts with other dockers or VMs my Unraid host. The problem is that I can't get to the webui. I try to connect to 'myunraidip:7818' and I get "This site can’t be reached x.x.x.x refused to connect." I can connect to :1880 and get the Nginx congratulations page. I did an Nmap scan of my host from another machine and I see all the ports I expect open, except 7818. Any ideas? buzz Quote Link to comment
Djoss Posted February 1, 2019 Author Share Posted February 1, 2019 6 hours ago, Marco L. said: I don't need the certificate from my Synology, my Synolody DSM needs the certificate generated by NPM : If you need the certificate only to access the Synology's UI, you could instead access it via NPM: Add a proxy host that forward to your local Synology IP address. Quote Link to comment
Djoss Posted February 1, 2019 Author Share Posted February 1, 2019 1 hour ago, buzzra said: I'm having a strange problem with this docker. I finally got the time to install it, and everything seemed to go fine. I left all the settings default, since there were no conflicts with other dockers or VMs my Unraid host. The problem is that I can't get to the webui. I try to connect to 'myunraidip:7818' and I get "This site can’t be reached x.x.x.x refused to connect." I can connect to :1880 and get the Nginx congratulations page. I did an Nmap scan of my host from another machine and I see all the ports I expect open, except 7818. Any ideas? buzz Do you have any error in the container's log? Also, the first time your start the container it may take longer for the UI to be ready (db needs to be created). Quote Link to comment
buzzra Posted February 2, 2019 Share Posted February 2, 2019 (edited) 8 hours ago, Djoss said: Do you have any error in the container's log? Also, the first time your start the container it may take longer for the UI to be ready (db needs to be created). There are no errors in the Nginx logs, but this is the init_db.log: Installing MariaDB/MySQL system tables in '/config/mysql' ... 2019-02-01 2:06:01 22916083571592 [ERROR] InnoDB: preallocating 12582912 bytes for file ./ibdata1 failed with error 95 2019-02-01 2:06:01 22916083571592 [ERROR] InnoDB: Could not set the file size of './ibdata1'. Probably out of disk space 2019-02-01 2:06:01 22916083571592 [ERROR] InnoDB: Database creation was aborted with error Generic error. You may need to delete the ibdata1 file before trying to start up again. 2019-02-01 2:06:01 22916083571592 [ERROR] Plugin 'InnoDB' init function returned error. 2019-02-01 2:06:01 22916083571592 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 2019-02-01 2:06:01 22916083571592 [ERROR] Unknown/unsupported storage engine: InnoDB 2019-02-01 2:06:01 22916083571592 [ERROR] Aborting Installation of system tables failed! Examine the logs in /config/mysql for more information. The problem could be conflicting information in an external my.cnf files. You can ignore these by doing: shell> /usr/bin/mysql_install_db --defaults-file=~/.my.cnf You can also try to start the mysqld daemon with: shell> /usr/bin/mysqld --skip-grant-tables --general-log & and use the command line tool /usr/bin/mysql to connect to the mysql database and look at the grant tables: shell> /usr/bin/mysql -u root mysql mysql> show tables; Try 'mysqld --help' if you have problems with paths. Using --general-log gives you a log in /config/mysql that may be helpful. The latest information about mysql_install_db is available at https://mariadb.com/kb/en/installing-system-tables-mysql_install_db You can find the latest source at https://downloads.mariadb.org and the maria-discuss email list at https://launchpad.net/~maria-discuss Please check all of the above before submitting a bug report at http://mariadb.org/jira It's definitely not a disk space problem as there is 369 GB available. edit: Sorry, after looking at my log file and going back through this topic, I see others have had this problem. My Settings -> Global Share Settings -> Tunable (enable DirectIO) is set to Auto. I have never changed it. My appdata share is normal as far as I know. I have a few other dockers running fine. It is on the cache drive, /mnt/user/appdata with 'use cache disk:' set to only. Edited February 2, 2019 by buzzra additional info Quote Link to comment
Djoss Posted February 4, 2019 Author Share Posted February 4, 2019 On 2/1/2019 at 7:27 PM, buzzra said: There are no errors in the Nginx logs, but this is the init_db.log: Installing MariaDB/MySQL system tables in '/config/mysql' ... 2019-02-01 2:06:01 22916083571592 [ERROR] InnoDB: preallocating 12582912 bytes for file ./ibdata1 failed with error 95 2019-02-01 2:06:01 22916083571592 [ERROR] InnoDB: Could not set the file size of './ibdata1'. Probably out of disk space 2019-02-01 2:06:01 22916083571592 [ERROR] InnoDB: Database creation was aborted with error Generic error. You may need to delete the ibdata1 file before trying to start up again. 2019-02-01 2:06:01 22916083571592 [ERROR] Plugin 'InnoDB' init function returned error. 2019-02-01 2:06:01 22916083571592 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 2019-02-01 2:06:01 22916083571592 [ERROR] Unknown/unsupported storage engine: InnoDB 2019-02-01 2:06:01 22916083571592 [ERROR] Aborting Installation of system tables failed! Examine the logs in /config/mysql for more information. The problem could be conflicting information in an external my.cnf files. You can ignore these by doing: shell> /usr/bin/mysql_install_db --defaults-file=~/.my.cnf You can also try to start the mysqld daemon with: shell> /usr/bin/mysqld --skip-grant-tables --general-log & and use the command line tool /usr/bin/mysql to connect to the mysql database and look at the grant tables: shell> /usr/bin/mysql -u root mysql mysql> show tables; Try 'mysqld --help' if you have problems with paths. Using --general-log gives you a log in /config/mysql that may be helpful. The latest information about mysql_install_db is available at https://mariadb.com/kb/en/installing-system-tables-mysql_install_db You can find the latest source at https://downloads.mariadb.org and the maria-discuss email list at https://launchpad.net/~maria-discuss Please check all of the above before submitting a bug report at http://mariadb.org/jira It's definitely not a disk space problem as there is 369 GB available. edit: Sorry, after looking at my log file and going back through this topic, I see others have had this problem. My Settings -> Global Share Settings -> Tunable (enable DirectIO) is set to Auto. I have never changed it. My appdata share is normal as far as I know. I have a few other dockers running fine. It is on the cache drive, /mnt/user/appdata with 'use cache disk:' set to only. So you have "Tunable (enable DirectIO)" set to Auto and it's not working? Can you try to temporarily set the config directory to something like "/tmp/NginxProxyManager" to see if it works? Quote Link to comment
buzzra Posted February 4, 2019 Share Posted February 4, 2019 14 hours ago, Djoss said: So you have "Tunable (enable DirectIO)" set to Auto and it's not working? Can you try to temporarily set the config directory to something like "/tmp/NginxProxyManager" to see if it works? Yep, works when set to /tmp/NginxProxyManager. Will not work set to any user share on the array or the cache drive. Any ideas why? I have other Dockers running fine using the appdata share on the cache drive. I also have VMs running on another cache drive only share. Thanks for the help buzz Quote Link to comment
Djoss Posted February 6, 2019 Author Share Posted February 6, 2019 On 2/4/2019 at 10:23 AM, buzzra said: Yep, works when set to /tmp/NginxProxyManager. Will not work set to any user share on the array or the cache drive. Any ideas why? I have other Dockers running fine using the appdata share on the cache drive. I also have VMs running on another cache drive only share. Thanks for the help buzz Could you try the following: Start the container. Login to the container: docker exec -ti NginxProxyManager sh Edit the file located at /etc/services.d/mysqld/run: vi /etc/services.d/mysqld/run Add the parameter "--innodb-flush-method=fsync" next to "/usr/bin/mysqld". Save and exit. Stop the container. Remove the appdata folder. Start the container. Quote Link to comment
buzzra Posted February 6, 2019 Share Posted February 6, 2019 5 hours ago, Djoss said: Could you try the following: Start the container. Login to the container: docker exec -ti NginxProxyManager sh Edit the file located at /etc/services.d/mysqld/run: vi /etc/services.d/mysqld/run Add the parameter "--innodb-flush-method=fsync" next to "/usr/bin/mysqld". Save and exit. Stop the container. Remove the appdata folder. Start the container. I followed the instructions above. Still not working. After removing the appdata folder and restarting the container, it comes up for a few seconds, creates the appdata folder and everything beneath it, and then stops. The init_db.log file is created with the same error. If I restart the container, it comes up and stays up, but I still can't get to the webui. I verified the changes to the 'run' file were still there. Here are the contents of current 'run' file and init_db.log: #!/usr/bin/with-contenv sh set -e # Exit immediately if a command exits with a non-zero status. set -u # Treat unset variables as an error. mkdir -p /run/mysqld chown $USER_ID:$GROUP_ID /run/mysqld echo "[$(basename "$(pwd)")] starting..." exec s6-applyuidgid -u $USER_ID -g $GROUP_ID -G ${SUP_GROUP_IDS:-$GROUP_ID} /usr/bin/mysqld --innodb-flush-method=fsync --datadir /config/mysql --tmpdir /tmp/ # vim:ft=sh:ts=4:sw=4:et:sts=4 Installing MariaDB/MySQL system tables in '/config/mysql' ... 2019-02-06 11:05:28 22602701859720 [ERROR] InnoDB: preallocating 12582912 bytes for file ./ibdata1 failed with error 95 2019-02-06 11:05:28 22602701859720 [ERROR] InnoDB: Could not set the file size of './ibdata1'. Probably out of disk space 2019-02-06 11:05:28 22602701859720 [ERROR] InnoDB: Database creation was aborted with error Generic error. You may need to delete the ibdata1 file before trying to start up again. 2019-02-06 11:05:28 22602701859720 [ERROR] Plugin 'InnoDB' init function returned error. 2019-02-06 11:05:28 22602701859720 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 2019-02-06 11:05:28 22602701859720 [ERROR] Unknown/unsupported storage engine: InnoDB 2019-02-06 11:05:28 22602701859720 [ERROR] Aborting Installation of system tables failed! Examine the logs in /config/mysql for more information. The problem could be conflicting information in an external my.cnf files. You can ignore these by doing: shell> /usr/bin/mysql_install_db --defaults-file=~/.my.cnf You can also try to start the mysqld daemon with: shell> /usr/bin/mysqld --skip-grant-tables --general-log & and use the command line tool /usr/bin/mysql to connect to the mysql database and look at the grant tables: shell> /usr/bin/mysql -u root mysql mysql> show tables; Try 'mysqld --help' if you have problems with paths. Using --general-log gives you a log in /config/mysql that may be helpful. The latest information about mysql_install_db is available at https://mariadb.com/kb/en/installing-system-tables-mysql_install_db You can find the latest source at https://downloads.mariadb.org and the maria-discuss email list at https://launchpad.net/~maria-discuss Please check all of the above before submitting a bug report at http://mariadb.org/jira Thanks for your time and help! buzz Quote Link to comment
scud133b Posted February 7, 2019 Share Posted February 7, 2019 I'm getting a 502 - Bad Gateway error when trying to connect to a Collabora docker I have set up through NPM. Here are settings I configured: Source: collabora.mysite.com Destination: https://server address:collabora-container-port Settings: https, cache assets disabled, block common exploits enabled, websockets enabled, access list publicly accessible, SSL cert matches the subdomain, force SSL enabled, http2 support enabled, no advanced config. DNS: CNAME record for collabora.mysite.com is forwarded at my registrar to my duckdns domain [Note: I already have working reverse proxies for containers on different subdomains, like for nextcloud]. TL;DR - I configured collabora the same as I've configured my other (working) NPM proxies -- but it's giving a 502 error. Any ideas? Quote Link to comment
Djoss Posted February 7, 2019 Author Share Posted February 7, 2019 1 hour ago, scud133b said: I'm getting a 502 - Bad Gateway error when trying to connect to a Collabora docker I have set up through NPM. Here are settings I configured: Source: collabora.mysite.com Destination: https://server address:collabora-container-port Settings: https, cache assets disabled, block common exploits enabled, websockets enabled, access list publicly accessible, SSL cert matches the subdomain, force SSL enabled, http2 support enabled, no advanced config. DNS: CNAME record for collabora.mysite.com is forwarded at my registrar to my duckdns domain [Note: I already have working reverse proxies for containers on different subdomains, like for nextcloud]. TL;DR - I configured collabora the same as I've configured my other (working) NPM proxies -- but it's giving a 502 error. Any ideas? I guess that accessing 9 hours ago, buzzra said: I followed the instructions above. Still not working. After removing the appdata folder and restarting the container, it comes up for a few seconds, creates the appdata folder and everything beneath it, and then stops. The init_db.log file is created with the same error. If I restart the container, it comes up and stays up, but I still can't get to the webui. I verified the changes to the 'run' file were still there. Here are the contents of current 'run' file and init_db.log: #!/usr/bin/with-contenv sh set -e # Exit immediately if a command exits with a non-zero status. set -u # Treat unset variables as an error. mkdir -p /run/mysqld chown $USER_ID:$GROUP_ID /run/mysqld echo "[$(basename "$(pwd)")] starting..." exec s6-applyuidgid -u $USER_ID -g $GROUP_ID -G ${SUP_GROUP_IDS:-$GROUP_ID} /usr/bin/mysqld --innodb-flush-method=fsync --datadir /config/mysql --tmpdir /tmp/ # vim:ft=sh:ts=4:sw=4:et:sts=4 Installing MariaDB/MySQL system tables in '/config/mysql' ... 2019-02-06 11:05:28 22602701859720 [ERROR] InnoDB: preallocating 12582912 bytes for file ./ibdata1 failed with error 95 2019-02-06 11:05:28 22602701859720 [ERROR] InnoDB: Could not set the file size of './ibdata1'. Probably out of disk space 2019-02-06 11:05:28 22602701859720 [ERROR] InnoDB: Database creation was aborted with error Generic error. You may need to delete the ibdata1 file before trying to start up again. 2019-02-06 11:05:28 22602701859720 [ERROR] Plugin 'InnoDB' init function returned error. 2019-02-06 11:05:28 22602701859720 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 2019-02-06 11:05:28 22602701859720 [ERROR] Unknown/unsupported storage engine: InnoDB 2019-02-06 11:05:28 22602701859720 [ERROR] Aborting Installation of system tables failed! Examine the logs in /config/mysql for more information. The problem could be conflicting information in an external my.cnf files. You can ignore these by doing: shell> /usr/bin/mysql_install_db --defaults-file=~/.my.cnf You can also try to start the mysqld daemon with: shell> /usr/bin/mysqld --skip-grant-tables --general-log & and use the command line tool /usr/bin/mysql to connect to the mysql database and look at the grant tables: shell> /usr/bin/mysql -u root mysql mysql> show tables; Try 'mysqld --help' if you have problems with paths. Using --general-log gives you a log in /config/mysql that may be helpful. The latest information about mysql_install_db is available at https://mariadb.com/kb/en/installing-system-tables-mysql_install_db You can find the latest source at https://downloads.mariadb.org and the maria-discuss email list at https://launchpad.net/~maria-discuss Please check all of the above before submitting a bug report at http://mariadb.org/jira Thanks for your time and help! buzz Can you try to add the same parameter, but to the call of "mysql_install_db" in /etc/cont-init.d/nginx-proxy-manager.sh? Quote Link to comment
Djoss Posted February 7, 2019 Author Share Posted February 7, 2019 1 hour ago, scud133b said: I'm getting a 502 - Bad Gateway error when trying to connect to a Collabora docker I have set up through NPM. Here are settings I configured: Source: collabora.mysite.com Destination: https://server address:collabora-container-port Settings: https, cache assets disabled, block common exploits enabled, websockets enabled, access list publicly accessible, SSL cert matches the subdomain, force SSL enabled, http2 support enabled, no advanced config. DNS: CNAME record for collabora.mysite.com is forwarded at my registrar to my duckdns domain [Note: I already have working reverse proxies for containers on different subdomains, like for nextcloud]. TL;DR - I configured collabora the same as I've configured my other (working) NPM proxies -- but it's giving a 502 error. Any ideas? So I guess that manually accessing "https://server address:collabora-container-port" is working? Try to look at logs under /mnt/user/appdata/NginxProxyManager/log/nginx/. You should find a message that provide more details about the failure. Quote Link to comment
scud133b Posted February 7, 2019 Share Posted February 7, 2019 (edited) On 2/6/2019 at 9:29 PM, Djoss said: So I guess that manually accessing "https://server address:collabora-container-port" is working? Try to look at logs under /mnt/user/appdata/NginxProxyManager/log/nginx/. You should find a message that provide more details about the failure. That's true BUT I seem to get a certificate error when I go there (I've added exceptions several times already). I'll grab the log and see what I can find. Edit: This appears to be it -- looks like the same URL that it grabs when I try to open a file in Collabora from Nextcloud. Interesting that the client in this error is my router's IP. 2019/02/07 07:38:34 [error] 1157#1157: *2343 upstream timed out (110: Operation timed out) while reading response header from upstream, client: [router IP], server: [nextcloud subdomain], request: "GET /index.php/apps/richdocuments/index?fileId=707&requesttoken=*** HTTP/2.0", upstream: "https://[nextcloud IP]:444/index.php/apps/richdocuments/index?fileId=707&requesttoken=***", host: "[nextcloud subdomain]" Edited February 9, 2019 by scud133b Quote Link to comment
Djoss Posted February 8, 2019 Author Share Posted February 8, 2019 20 hours ago, scud133b said: That's true BUT I seem to get a certificate error when I go there (I've added exceptions several times already). I'll grab the log and see what I can find. Edit: This appears to be it -- looks like the same URL that it grabs when I try to open a file in Collabora from Nextcloud. Interesting that the client in this error is my router's IP. 2019/02/07 07:38:34 [error] 1157#1157: *2343 upstream timed out (110: Operation timed out) while reading response header from upstream, client: [router IP], server: [nextcloud subdomain], request: "GET /index.php/apps/richdocuments/index?fileId=707&requesttoken=PMfaSZb6qUrrKWuGg3VhIN%2FwV0SNa0RBDGstqKvvuAk%3D%3Ae7WsA6HC3wKTXTy38Q9OUeuxBx60BiAFVFhhw9Gl2n8%3D HTTP/2.0", upstream: "https://[nextcloud IP]:444/index.php/apps/richdocuments/index?fileId=707&requesttoken=PMfaSZb6qUrrKWuGg3VhIN%2FwV0SNa0RBDGstqKvvuAk%3D%3Ae7WsA6HC3wKTXTy38Q9OUeuxBx60BiAFVFhhw9Gl2n8%3D", host: "[nextcloud subdomain]" And from the Collabora side, do you have any log that could help? Quote Link to comment
scud133b Posted February 9, 2019 Share Posted February 9, 2019 15 hours ago, Djoss said: And from the Collabora side, do you have any log that could help? I'm looking for something but I'm not great with the command line inside docker. The Collabora container doesn't log anything to appdata like yours does, unfortunately. Quote Link to comment
scud133b Posted February 9, 2019 Share Posted February 9, 2019 (edited) @Djoss I've noticed that there appears to be a consistent issue when I try to access my apps using the domain name from the same LAN as the server. I have a couple VMs that I point to with NPM and those also experience the timeout error, occasionally. And that timeout error is actually failing at my router's IP address so I suspect maybe it's something there that is blocking it when the connection originates internally. If I try to connect to these containers or VMs from mobile phone, it works right away without any errors logged in NPM. Any ideas what to look for? Edited February 9, 2019 by scud133b Quote Link to comment
buzzra Posted February 10, 2019 Share Posted February 10, 2019 On 2/6/2019 at 9:28 PM, Djoss said: I guess that accessing Can you try to add the same parameter, but to the call of "mysql_install_db" in /etc/cont-init.d/nginx-proxy-manager.sh? Still no good. cannot get to the webui. Still the same errors creating the database. init_db.log: Installing MariaDB/MySQL system tables in '/config/mysql' ... 2019-02-09 12:42:35 23429459561352 [ERROR] InnoDB: preallocating 12582912 bytes for file ./ibdata1 failed with error 95 2019-02-09 12:42:35 23429459561352 [ERROR] InnoDB: Could not set the file size of './ibdata1'. Probably out of disk space 2019-02-09 12:42:35 23429459561352 [ERROR] InnoDB: Database creation was aborted with error Generic error. You may need to delete the ibdata1 file before trying to start up again. 2019-02-09 12:42:36 23429459561352 [ERROR] Plugin 'InnoDB' init function returned error. 2019-02-09 12:42:36 23429459561352 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 2019-02-09 12:42:36 23429459561352 [ERROR] Unknown/unsupported storage engine: InnoDB 2019-02-09 12:42:36 23429459561352 [ERROR] Aborting Installation of system tables failed! Examine the logs in /config/mysql for more information. The problem could be conflicting information in an external my.cnf files. You can ignore these by doing: shell> /usr/bin/mysql_install_db --defaults-file=~/.my.cnf You can also try to start the mysqld daemon with: shell> /usr/bin/mysqld --skip-grant-tables --general-log & and use the command line tool /usr/bin/mysql to connect to the mysql database and look at the grant tables: shell> /usr/bin/mysql -u root mysql mysql> show tables; Try 'mysqld --help' if you have problems with paths. Using --general-log gives you a log in /config/mysql that may be helpful. The latest information about mysql_install_db is available at https://mariadb.com/kb/en/installing-system-tables-mysql_install_db You can find the latest source at https://downloads.mariadb.org and the maria-discuss email list at https://launchpad.net/~maria-discuss Please check all of the above before submitting a bug report at http://mariadb.org/jira Sorry for the trouble. Thanks for the help buzz Quote Link to comment
Ghostwalker42 Posted February 12, 2019 Share Posted February 12, 2019 Hi All, I'm new to this form and I dont know if this question was already asked. I installed Nginx Proxy Manager on my unraid box and configured it to use port 80,443, 7818 but it seems like the configs did not take affect. It will only proxy my site though port 8080. I have attached screen shots of my config. Any help on this would be most appreciated. Thanks Quote Link to comment
Djoss Posted February 12, 2019 Author Share Posted February 12, 2019 On 2/9/2019 at 2:32 PM, scud133b said: @Djoss I've noticed that there appears to be a consistent issue when I try to access my apps using the domain name from the same LAN as the server. I have a couple VMs that I point to with NPM and those also experience the timeout error, occasionally. And that timeout error is actually failing at my router's IP address so I suspect maybe it's something there that is blocking it when the connection originates internally. If I try to connect to these containers or VMs from mobile phone, it works right away without any errors logged in NPM. Any ideas what to look for? Depending on your router, you may need to do additional configuration to properly access via your DNS name from your local network. Look for something called "NAT reflection". Quote Link to comment
Djoss Posted February 12, 2019 Author Share Posted February 12, 2019 On 2/9/2019 at 7:56 PM, buzzra said: Sorry for the trouble. Thanks for the help buzz Not sure what is the root cause of the issue. There is probably a setting somewhere in unRAID that cause this. What is the filesystem of your disks? Quote Link to comment
Djoss Posted February 12, 2019 Author Share Posted February 12, 2019 21 minutes ago, Ghostwalker42 said: Hi All, I'm new to this form and I dont know if this question was already asked. I installed Nginx Proxy Manager on my unraid box and configured it to use port 80,443, 7818 but it seems like the configs did not take affect. It will only proxy my site though port 8080. I have attached screen shots of my config. Any help on this would be most appreciated. Thanks Looks like you are not using the "Bridge" network type. Quote Link to comment
Ghostwalker42 Posted February 12, 2019 Share Posted February 12, 2019 1 minute ago, Djoss said: Looks like you are not using the "Bridge" network type. I'm using a bridge network, Should I use something else? Quote Link to comment
Djoss Posted February 12, 2019 Author Share Posted February 12, 2019 22 minutes ago, Ghostwalker42 said: I'm using a bridge network, Should I use something else? You should use the "Bridge" network, not "brX". They are very different modes... Quote Link to comment
Ghostwalker42 Posted February 12, 2019 Share Posted February 12, 2019 7 minutes ago, Djoss said: different mod I make the change and got an error on the container. root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='NginxProxyManager' --net='bridge' -e TZ="America/New_York" -e HOST_OS="Unraid" -e 'USER_ID'='99' -e 'GROUP_ID'='100' -e 'UMASK'='000' -e 'APP_NICENESS'='' -p '7818:8181/tcp' -p '80:8080/tcp' -p '443:4443/tcp' -v '/mnt/user/appdata/NginxProxyManager':'/config':'rw' 'jlesage/nginx-proxy-manager' 1326cdb5a9b92f53de57223388cd1d9072b11c69c8b0fa73d73ce70b45dc0537 /usr/bin/docker: Error response from daemon: driver failed programming external connectivity on endpoint NginxProxyManager (26b4a97add4c658413cbc8924b1a8e868409759809d132c4547c95ee547801d9): Error starting userland proxy: listen tcp 0.0.0.0:80: bind: address already in use. The command failed. Quote Link to comment
buzzra Posted February 12, 2019 Share Posted February 12, 2019 (edited) 41 minutes ago, Djoss said: Not sure what is the root cause of the issue. There is probably a setting somewhere in unRAID that cause this. What is the filesystem of your disks? Funny you should ask. I was researching this too since my last post. My filesystem is ReiserFS, since I have had my Unraid up for quite a few years. I was thinking this may be the problem, because the only things I see about it online are problems with Windows NTFS and Mac HFS. I can move my cache drive to XFS, but that's not going to be any time soon. Does anyone else have this container running on a ReiserFS system? Any other suggestions are welcome. Thanks again for all your time on this. buzz Edited February 12, 2019 by buzzra spelling Quote Link to comment
scud133b Posted February 13, 2019 Share Posted February 13, 2019 8 hours ago, Djoss said: Depending on your router, you may need to do additional configuration to properly access via your DNS name from your local network. Look for something called "NAT reflection". That sounds like it might be it. I have ATT fiber which means I can't fix this unless I buy a new router that can bypass the ATT gateway. ugh. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.