Troubleshooting
Common issues and steps you can take to fix them.
General Issues
Feature(s) Stopped Working After Updating to Latest Version
Your browser might have cached an older version of a JavaScript(JS) file which is no longer compatible with the current version of LubeLogger. Try the following steps:
- Verify - Try navigating to LubeLogger in Incognito mode.
- If everything functions as expected in Incognito, you have a caching issue.
- Clear your browser's cache or perform a hard reload(hit CTRL+SHIFT+R multiple times on most browsers)
Can't Send Email via SMTP
Note that for most email providers, you can no longer use your account password to authenticate and must instead generate an app password for LubeLogger to be able to authenticate on your behalf to your email provider's SMTP server.
If you've downloaded the .env file from the GitHub repo, there is an issue with how the file gets formatted when it is downloaded, you will have to copy the contents and re-create one manually on your machine.
Console shows Authentication Errors
Those are purely informational, add this line in your environment variables to prevent information logs from showing up in the console.
LOGGING__LOGLEVEL__DEFAULT=Error
Locale Issues
Can't input values in "," format / shows up as 0.
Ensure that your locale environment variables are configured correctly, note that if running via docker, both environment variables LANG and LC_ALL have to be identical.
Locale Not Updating/¤ Currency Symbol/Date Format Issues
Try the following steps:
- Check if the environment variables are injected correctly(does SMTP/OICD configurations work)
- Re-deploy Container
- If that doesn't work, try re-creating the
.env
file - If using Portainer/Synology, you might have to enter the environment variables manually.
- One last thing to try: copy and paste the environment variables into docker-compose.yml
Postgres Issues
Schema Does Not Exist
Make sure that there is a schema named "app" in the database as specified in the Postgres connection string. See Postgres
Server Issues
Can't Access LubeLogger Instance from Other Devices
This problem is specific to the Windows Standalone Executable, the problem stems from the fact that Kestrel is configured by default to listen on and only on localhost. In order to get around this, you will need to retrieve the IPv4 address of your local machine, and add the following section into appsettings.json
Note: replace 10.0.0.4:5000/5011
with your local ip address and port
"Kestrel": { "Endpoints": { "Http": { "Url": "http://10.0.0.4:5000" }, "Https": { "Url": "https://10.0.0.4:5011" }, }
Additionally, see Setting up HTTPS for HTTPS/SSL Cert Configuration
ERR_TOO_MANY_REDIRECTS
If you encounter this error in your browser while attempting to navigate to your LubeLogger instance and it is accompanied by the following console error in your Docker Container:
The configured user limit (128) on the number of inotify instances has been reached
You have reached the maximum limit of file watchers across all your Docker Containers. In LubeLogger, file watchers are crucial for detecting changes to configuration files. To fix this, you will need to increase the inotify limit above 128.
NGINX / Cloudflare
LubeLogger is a web app that runs on Kestrel, it literally doesn't matter if it's deployed behind a reverse proxy or Cloudflare tunnel. As long as the app can receive traffic on the port it's configured on, it will run.
Here's a sample Nginx reverse proxy configuration courtesy of thehijacker
server { listen 443 ssl http2; server_name lubelogger.domain.com; ssl_certificate /etc/nginx/ssl/acme/domain.com/fullchain.pem; ssl_certificate_key /etc/nginx/ssl/acme/domain.com/key.pem; ssl_dhparam /etc/nginx/ssl/acme/domain.com/dhparams.pem; ssl_trusted_certificate /etc/nginx/ssl/acme/domain.com/fullchain.pem; location / { proxy_pass http://192.168.28.53:8289; client_max_body_size 50000M; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_redirect off; } }