My error. I had the site stuck in recovery mode. It is back up now.

I am back to normal. Thanks

@girish

I became confused as I was not getting emails for the new accounts I was creating and mistaken the restatement of the username as a password I had set. (I created the users one day, and then tried to use them to login several days later when you told me I could do this).

My error. But I am now into several apps. This is great. I don't even have to worry about setting the password in apps. Fantastic. I need to next look into why it is not creating new emails after I create a user. I checked the spam folder as well. Thanks for your help.

@girish

Yes, I was using a capital in the username. Now I have access after creating a new user with no caps. Thanks.

@girish

Yes, I was using a capital in the username. Now I have access after creating a new user with no caps. Thanks.

@girish

The log says that it delivered mail, but I don't see it in Gmail. But I tried my other email service and it worked.

I am still having a problem with Jupyter Notebook. That is rejecting the same password that is working in all the other apps.

@girish

I became confused as I was not getting emails for the new accounts I was creating and mistaken the restatement of the username as a password I had set. (I created the users one day, and then tried to use them to login several days later when you told me I could do this).

My error. But I am now into several apps. This is great. I don't even have to worry about setting the password in apps. Fantastic. I need to next look into why it is not creating new emails after I create a user. I checked the spam folder as well. Thanks for your help.

Ahh, just saw this. Ok, I am following it up on the other thread as it is the same issue. Thanks.

Girish,

Seems like a great feature. However, I tried logging in with my username and passwords from Cloudron into several of my apps, but none of them accepted the usernames and passwords I created. I saw the selection you are referring to when I brought up each new app, that is to make it compatible with Cloudron users. I had been doing this previously (accepting the default), but did not know what it meant.

I wonder what I am doing wrong.

I have no idea how to login to Surfer. It is strange that it does not come with a default login. There are not files to be adjusted where I could enter a login either. Does anyone know how to create a user and login for Surfer?

I have been looking through the app, and online, but can't find where or how the username and password is set. I tried this command in the terminal.

./admin user-add --username test --password test --display-name "Test User"

But it did not work.

My error. I had the site stuck in recovery mode. It is back up now.

I am back to normal. Thanks

@girish This is the information after the backup yesterday, and when the problem started.

Oct 05 23:00:04 backing up
Oct 05 23:00:04 217:M 06 Oct 06:00:04.479 * DB saved on disk
Oct 06 09:58:07 2020-10-06 16:58:07,653 WARN received SIGTERM indicating exit request
Oct 06 09:58:07 2020-10-06 16:58:07,653 INFO waiting for redis, redis-service to die
Oct 06 09:58:07 2020-10-06 16:58:07,654 INFO stopped: redis-service (terminated by SIGTERM)
Oct 06 09:58:07 217:signal-handler (1602003487) Received SIGTERM scheduling shutdown...
Oct 06 09:58:07 217:M 06 Oct 16:58:07.659 # User requested shutdown...
Oct 06 09:58:07 217:M 06 Oct 16:58:07.659 * Saving the final RDB snapshot before exiting.
Oct 06 09:58:07 217:M 06 Oct 16:58:07.660 * DB saved on disk
Oct 06 09:58:07 217:M 06 Oct 16:58:07.660 * Removing the pid file.
Oct 06 09:58:07 217:M 06 Oct 16:58:07.660 # Redis is now ready to exit, bye bye...
Oct 06 09:58:07 2020-10-06 16:58:07,660 INFO stopped: redis (exit status 0)
Oct 06 10:01:10 Generating SSL certificate
Oct 06 10:01:10 Generating a RSA private key
Oct 06 10:01:10 ........+++++
Oct 06 10:01:10 ............+++++
Oct 06 10:01:10 writing new private key to '/run/redis.cloudron.key'
Oct 06 10:01:10 -----
Oct 06 10:01:10 Starting supervisor
Oct 06 10:01:10 2020-10-06 17:01:10,173 CRIT Supervisor running as root (no user in config file)
Oct 06 10:01:10 2020-10-06 17:01:10,173 INFO Included extra file "/etc/supervisor/conf.d/redis-service.conf" during parsing
Oct 06 10:01:10 2020-10-06 17:01:10,173 INFO Included extra file "/etc/supervisor/conf.d/redis.conf" during parsing
Oct 06 10:01:10 2020-10-06 17:01:10,180 INFO RPC interface 'supervisor' initialized
Oct 06 10:01:10 2020-10-06 17:01:10,180 CRIT Server 'inet_http_server' running without any HTTP authentication checking
Oct 06 10:01:10 2020-10-06 17:01:10,180 INFO RPC interface 'supervisor' initialized
Oct 06 10:01:10 2020-10-06 17:01:10,180 CRIT Server 'unix_http_server' running without any HTTP authentication checking
Oct 06 10:01:10 2020-10-06 17:01:10,180 INFO supervisord started with pid 1
Oct 06 10:01:11 2020-10-06 17:01:11,184 INFO spawned: 'redis' with pid 15
Oct 06 10:01:11 2020-10-06 17:01:11,187 INFO spawned: 'redis-service' with pid 16
Oct 06 10:01:11 15:C 06 Oct 17:01:11.195 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
Oct 06 10:01:11 15:C 06 Oct 17:01:11.195 # Redis version=4.0.9, bits=64, commit=00000000, modified=0, pid=15, just started
Oct 06 10:01:11 15:C 06 Oct 17:01:11.195 # Configuration loaded
Oct 06 10:01:11 15:M 06 Oct 17:01:11.196 * Running mode=standalone, port=6379.
Oct 06 10:01:11 15:M 06 Oct 17:01:11.196 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
Oct 06 10:01:11 15:M 06 Oct 17:01:11.196 # Server initialized
Oct 06 10:01:11 15:M 06 Oct 17:01:11.196 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
Oct 06 10:01:11 15:M 06 Oct 17:01:11.196 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
Oct 06 10:01:11 15:M 06 Oct 17:01:11.197 * DB loaded from disk: 0.000 seconds
Oct 06 10:01:11 15:M 06 Oct 17:01:11.197 * Ready to accept connections
Oct 06 10:01:11 Redis service endpoint listening on https://:::3000
Oct 06 10:01:12 2020-10-06 17:01:12,288 INFO success: redis entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
Oct 06 10:01:12 2020-10-06 17:01:12,288 INFO success: redis-service entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

@girish I did see the 404 page before, but after restarting, and also changing the URL back to what it was through the Cloudron UI, I see the 502 Bad Gateway error.