Troubleshooting
This document contains common problems and their solutions.
Please ensure your issue isn't listed here, before opening a new ticket.Found something not listed here? Consider adding it, to help other users.
Contentsβ
- Config not saving
- Refused to Connect in Web Content View
- 404 On Static Hosting
- 404 from Mobile Home Screen
- Yarn Build or Run Error
- Remote Config Not Loading
- Heap limit Allocation failed
- Command failed with signal "SIGKILL"
- Auth Validation Error: "should be object"
- App Not Starting After Update to 2.0.4
- Keycloak Redirect Error
- Docker Directory Error
- Config not Saving on Vercel / Netlify / CDN
- Config Not Updating
- Config Still not Updating
- Styles and Assets not Updating
- DockerHub toomanyrequests
- Config Validation Errors
- Node Sass unsupported environment
- Unreachable Code Error
- Cannot find module './_baseValues'
- Ngrok Invalid Host Headers
- Warnings in the Console during deploy
- Docker Login Fails on Ubuntu
- Status Checks Failing
- Diagnosing Widget Errors
- Fixing Widget CORS Errors
- Widget Shows Error Incorrectly
- Weather Forecast Widget 401
- Widget Displaying Inaccurate Data
- Font Awesome Icons not Displaying
- Copy to Clipboard not Working
- Unsupported Digital Envelope Routines
- How to Reset Local Settings
- How to make a bug report
- How-To Open Browser Console
- Git Contributions not Displaying
Config not savingβ
Possible Issue 1: Unable to call save endpoint from CDN/static serverβ
If you're running Dashy using a static hosting provider (like Vercel), then there is no Node server, and so the save config action will not work via the UI.
You'll instead need to copy the YAML after making your changes, and paste that into your conf.yml directly. If you've connected Vercel to git, then these changes will take effect automatically, once you commit your changes.
Look here for more information: https://dashy.to/docs/deployment#deploy-to-cloud-service
If you're running on Netlify, there are some cloud functions which take care of all the server endpoints (like status checking), so these will work as expected.
See also #1465
Possible Issue 2: Unable to saveβ
In Docker, double check that the file isn't read-only, and that the container actually has permissions to modify it. You shouldn't really be running it as a root user, and I'm not sure if it will work if you do-
Possible Issue 3: Saved but not updatingβ
After saving, the frontend will recompile, which may take a couple seconds (or a bit longer on a Pi or low-powered device). If it doesn't recompile, you can manually trigger a re-build.
Refused to Connect in Modal or Workspace Viewβ
This is not an issue with Dashy, but instead caused by the target app preventing direct access through embedded elements.
As defined in RFC-7034, for any web content to be accessed through an embedded element, it must have the X-Frame-Options HTTP header set to ALLOW. If you are getting a Refused to Connect error then this header is set to DENY (or SAMEORIGIN and it's on a different host). Thankfully, for self-hosted services, it is easy to set these headers.
These settings are usually set in the config file for the web server that's hosting the target application, here are some examples of how to enable cross-origin access with common web servers:
NGINXβ
In NGINX, you can use the add_header module within the app block.
server {
...
add_header X-Frame-Options SAMEORIGIN always;
}
Then reload with service nginx reload
Caddyβ
In Caddy, you can use the header directive.
header {
X-Frame-Options SAMEORIGIN
}
Apacheβ
In Apache, you can use the mod_headers module to set the X-Frame-Options in your config file. This file is usually located somewhere like `/etc/apache2/httpd.conf
Header set X-Frame-Options: "ALLOW-FROM http://[dashy-location]/"
LightHttpdβ
Content-Security-Policy: frame-ancestors 'self' https://[dashy-location]/
404 On Static Hostingβ
If you're seeing Dashy's 404 page on initial load/ refresh, and then the main app when you go back to Home, then this is likely caused by the Vue router, and if so can be fixed in one of two ways.
The first solution is to switch the routing mode, from HTML5 history mode to hash mode, by setting appConfig.routingMode to hash.
If this works, but you wish to continue using HTML5 history mode, then a bit of extra server configuration is required. This is explained in more detaail in the Vue Docs. Once completed, you can then use routingMode: history again, for neater URLs.
404 after Launch from Mobile Home Screenβ
Similar to the above issue, if you get a 404 after using iOS and Android's "Add to Home Screen" feature, then this is caused by Vue router.
It can be fixed by setting appConfig.routingMode to hash
404 On Multi-Page Appsβ
Similar to above, if you get a 404 error when visiting a page directly on multi-page apps, then this can be fixed under appConfig, by setting routingMode to hash. Then rebuilding, and refreshing the page.
Yarn Errorβ
For more info, see Issue #1
First of all, check that you've got yarn installed correctly - see the yarn installation docs for more info.
If you're getting an error about scenarios, then you've likely installed the wrong yarn... (you're not the only one!). You can fix it by uninstalling, adding the correct repo, and reinstalling, for example, in Debian:
sudo apt remove yarncurl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add -echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.listsudo apt update && sudo apt install yarn
Alternatively, as a workaround, you have several options:
- Try using NPM instead: So clone, cd, then run
npm install,npm run buildandnpm start - Try using Docker instead, and all of the system setup and dependencies will already be taken care of. So from within the directory, just run
docker build -t lissy93/dashy .to build, and then use docker start to run the project, e.g:docker run -it -p 8080:8080 lissy93/dashy(see the deploying docs for more info)
Remote Config Not Loadingβ
If you've got a multi-page dashboard, and are hosting the additional config files yourself, then CORS rules will apply. A CORS error will look something like:
Access to XMLHttpRequest at 'https://example.com/raw/my-config.yml' from origin 'http://dashy.local' has been blocked by CORS policy:
No 'Access-Control-Allow-Origin' header is present on the requested resource.
The solution is to add the appropriate headers onto the target server, to allow it to accept requests from the origin where you're running Dashy.
If it is a remote service, that you do not have admin access to, then another option is to proxy the request. Either host your own, or use a publicly accessible service, like allorigins.win, e.g: https://api.allorigins.win/raw?url=https://pastebin.com/raw/4tZpaJV5. For git-based services specifically, there's raw.githack.com
Ineffective mark-compacts near heap limit Allocation failedβ
If you see an error message, similar to:
<--- Last few GCs --->
[61:0x74533040] 229060 ms: Mark-sweep (reduce) 127.1 (236.9) -> 127.1 (137.4) MB, 5560.7 / 0.3 ms (average mu = 0.286, current mu = 0.011) allocation failure scavenge might not succeed
<--- JS stacktrace --->
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
This is likely caused by insufficient memory allocation to the container. When the container first starts up, or has to rebuild, the memory usage spikes, and if there isn't enough memory, it may terminate. This can be specified with, for example: --memory=1024m. For more info, see Docker: Runtime options with Memory, CPUs, and GPUs.
See also: #380, #350, #297, #349, #510, #511 and #834
Command failed with signal "SIGKILL"β
In Docker, this can be caused by not enough memory. When the container first starts up, or has to rebuild, the memory usage spikes, and so a larger allocation may be required. This can be specified with, for example: --memory=1024m. For more info, see Docker: Runtime options with Memory, CPUs, and GPUs
See also #624
Auth Validation Error: "should be object"β
In V 1.6.5 an update was made that in the future will become a breaking change. You will need to update you config to reflect this before V 2.0.0 is released. In the meantime, your previous config will continue to function normally, but you will see a validation warning. The change means that the structure of the appConfig.auth object is now an object, which has a users property.
For more info, see this announcement.
You can fix this by replacing:
auth:
- user: xxx
hash: xxx
with
auth:
users:
- user: xxx
hash: xxx
App Not Starting After Update to 2.0.4β
Version 2.0.4 introduced changes to how the config is read, and the app is build. If you were previously mounting /public as a volume, then this will over-write the build app, preventing it from starting. The solution is to just pass in the file(s) / sub-directories that you need. For example:
volumes:
- /srv/dashy/conf.yml:/app/user-data/conf.yml
- /srv/dashy/item-icons:/app/public/item-icons
Keycloak Redirect Errorβ
Check the browser's console output, if you've not set any headers, you will likely see a CORS error here, which would be the source of the issue.
You need to allow Dashy to make requests to Keycloak, and Keycloak to redirect to Dashy. The way you do this depends on how you're hosting these applications / which proxy you are using, and examples can be found in the Management Docs.
For example, add the access control header to Keycloak, like:
Access-Control-Allow-Origin [URL-of Dashy]
Note that for requests that transport sensitive info like credentials, setting the accept header to a wildcard (*) is not allowed - see MDN Docs, so you will need to specify the actual URL.
You should also ensure that Keycloak is correctly configured, with a user, realm and application, and be sure that you have set a valid redirect URL in Keycloak (screenshot).
For more details on how to set headers, see the Example Headers in the management docs, or reference the documentation for your proxy.
If you're running in Kubernetes, you will need to enable CORS ingress rules, see docs, e.g:
nginx.ingress.kubernetes.io/cors-allow-origin: "https://dashy.example.com"
nginx.ingress.kubernetes.io/enable-cors: "true"
See also: #479, #409, #507, #491, #341, #520
Docker Directoryβ
Error response from daemon: OCI runtime create failed: container_linux.go:380:
starting container process caused: process_linux.go:545: container init caused:
rootfs_linux.go:76: mounting "/home/ubuntu/my-conf.yml" to rootfs at
"/app/user-data/conf.yml" caused: mount through procfd: not a directory:
unknown: Are you trying to mount a directory onto a file (or vice-versa)?
Check if the specified host path exists and is the expected type.
If you get an error similar to the one above, you are mounting a directory to the config file's location, when a plain file is expected. Create a YAML file, (touch my-conf.yml), populate it with a sample config, then pass it as a volume: -v ./my-local-conf.yml:/app/user-data/conf.yml
Config not Saving on Vercel / Netlify / CDNβ
If you're running Dashy using a static hosting provider (like Vercel), then there is no Node server, and so the save config action will not work via the UI.
You'll instead need to copy the YAML after making your changes, and paste that into your conf.yml directly. If you've connected Vercel to git, then these changes will take effect automatically, once you commit your changes.
If you're running on Netlify, there are some cloud functions which take care of all the server endpoints (like status checking), so these will work as expected.
See also #1465
Config Not Updatingβ
Dashy has the option to save settings and config locally, in browser storage. Anything here will take precedence over whatever is in your config file, sometimes with unintended consequences. If you've updated the config file manually, and are not seeing changes reflected in the UI, then try visiting the site in Incognito mode. If that works, then the solution is just to clear local storage. This can be done from the config menu, under "Clear Local Settings".
Config Still not Updatingβ
Sometimes your text editor updates files inode, meaning changes will not be picked up by the Docker container. This article explains things further.
Styles and Assets not Updatingβ
If you find that your styles and other visual assets work when visiting ip:port by not dashy.domain.com, then this is usually caused by caching. In your browser, do a hard-refresh (Ctrl + F5). If you use Cloudflare, then you can clear the cache through the management console, or set the cache level to Bypass for certain files, under the Rules tab.
DockerHub toomanyrequestsβ
This situation relates to error messages similar to one of the following, returned when pulling, updating or running the Docker container from Docker Hub.
Continuing execution. Pulling image lissy93/dashy:release-1.6.0
error pulling image configuration: toomanyrequests
or
You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit
When DockerHub returns one of these errors, or a 429 status, that means you've hit your rate limit. This was introduced last year, and prevents unauthenticated or free users from running docker pull more than 100 times per 6 hours.
You can check your rate limit status by looking for the ratelimit-remaining header in any DockerHub responses.
Solution 1 - Use an alternate container registryβ
- Dashy is also available through GHCR, which at present does not have any hard limits. Just use
docker pull ghcr.io/lissy93/dashy:latestto fetch the image - You can also build the image from source, by cloning the repo, and running
docker build -t dashy .or use the pre-made docker compose
Solution 2 - Increase your rate limitsβ
- Logging in to DockerHub will increase your rate limit from 100 requests to 200 requests per 6 hour period
- Upgrading to a Pro for $5/month will increase your image requests to 5,000 per day, and any plans above have no rate limits
- Since rate limits are counted based on your IP address, proxying your requests, or using a VPN may work
Config Validation Errorsβ
The configuration file is validated against Dashy's Schema using AJV.
First, check that your syntax is valid, using YAML Validator or JSON Validator. If the issue persists, then take a look at the schema, and verify that the field you are trying to add/ modify matches the required format. You can also use this tool to validate your JSON config against the schema, or run yarn validate-config.
If you're trying to use a recently released feature, and are getting a warning, this is likely because you've not yet updated the the current latest version of Dashy.
If the issue still persists, you should raise an issue.
Node Sass does not yet support your current environmentβ
Caused by node-sass's binaries being built for a for a different architecture
To fix this, just run: yarn rebuild node-sass
Unreachable Code Errorβ
An error similar to: Fatal error in , line 0. Unreachable code, FailureMessage Object: 0xffe6c8ac. Illegal instruction (core dumped)
Is related to a bug in a downstream package, see nodejs/docker-node#1477.
Usually, updating your system and packages will resolve the issue.
See also: #776
Error: Cannot find module './_baseValues'β
Clearing the cache should fix this: yarn cache clean
If the issue persists, remove (rm -rf node_modules\ yarn.lock) and reinstall (yarn) node_modules
Invalid Host Header while running through ngrokβ
Just add the -host-header flag, e.g. ngrok http 8080 -host-header="localhost:8080"
Warnings in the Console during deployβ
Please acknowledge the difference between errors and warnings before raising an issue about messages in the console. It's not unusual to see warnings about a new version of a certain package being available, an asset bundle bing oversized or a service worker not yet having a cache. These shouldn't have any impact on the running application, so please don't raise issues about these unless it directly relates to a bug or issue you're experiencing. Errors on the other hand should not appear in the console, and they are worth looking into further.
Docker Login Fails on Ubuntuβ
Run sudo apt install gnupg2 pass && gpg2 -k
Status Checks Failingβ
If you're using status checks, and despite a given service being online, the check is displaying an error, there are a couple of things you can look at:
If your service requires requests to include any authorization in the headers, then use the statusCheckHeaders property, as described in the docs.
If you are still having issues, it may be because your target application is blocking requests from Dashy's IP. This is a CORS error, and can be fixed by setting the headers on your target app, to include:
Access-Control-Allow-Origin: https://location-of-dashy/
Vary: Origin
If the URL you are checking has an unsigned certificate, or is not using HTTPS, then you may need to disable the rejection of insecure requests. This can be done by setting statusCheckAllowInsecure to true for a given item.
If your service is online, but responds with a status code that is not in the 2xx range, then you can use statusCheckAcceptCodes to set an accepted status code.
If you get an error, like Service Unavailable: Server resulted in a fatal error, even when it's definitely online, this is most likely caused by missing the protocol. Don't forget to include https:// (or whatever protocol) before the URL, and ensure that if needed, you've specified the port.
Running Dashy in HOST network mode, instead of BRIDGE will allow status check access to other services in HOST mode. For more info, see #445.
If you have firewall rules configured, then ensure that they don't prevent Dashy from making requests to the other services you are trying to access.
Currently, the status check needs a page to be rendered, so if this URL in your browser does not return anything, then status checks will not work. This may be modified in the future, but in the meantime, a fix would be to make your own status service, which just checks if your app responds with whatever code you'd like, and then return a 200 plus renders an arbitrary message. Then just point statusCheckUrl to your custom page.
For further troubleshooting, use an application like Postman to diagnose the issue. Set the parameter to GET, and then make a call to: https://[url-of-dashy]/status-check/?&url=[service-url]. Where the service URL must have first been encoded (e.g. with encodeURIComponent() or urlencoder.io)
If you're serving Dashy though a CDN, instead of using the Node server or Docker image, then the Node endpoint that makes requests will not be available to you, and all requests will fail. A workaround for this may be implemented in the future, but in the meantime, your only option is to use the Docker or Node deployment method.
Widget Errorsβ
Find Error Messageβ
If an error occurs when fetching or rendering results, you will see a short message in the UI. If that message doesn't adequately explain the problem, then you can open the browser console to see more details.
Check Configβ
Before proceeding, ensure that if the widget requires auth your API is correct, and for custom widgets, double check that the URL and protocol is correct.
Timeout Errorβ
If the error message in the console includes: Error: timeout of 500ms exceeded, then your Glances endpoint is slower to respond than expected. You can fix this by setting timeout to a larger value. This is done on each widget, with the timeout attribute, and is specified in ms. E.g. timeout: 5000 would only fail if no response is returned within 5 seconds.
CORS errorβ
If the console message mentions to corss-origin blocking, then this is a CORS error, see: Fixing Widget CORS Errors
More Infoβ
If you're able to, you can find more information about why the request may be failing in the Dev Tools under the Network tab, and you can ensure your endpoint is correct and working using a tool like Postman.
Widget CORS Errorsβ
The most common widget issue is a CORS error. This is a browser security mechanism which prevents the client-side app (Dashy) from from accessing resources on a remote origin, without that server's explicit permission (e.g. with headers like Access-Control-Allow-Origin). See the MDN Docs for more info: Cross-Origin Resource Sharing.
There are several ways to fix a CORS error:
Option 1 - Ensure Correct Protocolβ
You will get a CORS error if you try and access a http service from a https source. So ensure that the URL you are requesting has the right protocol, and is correctly formatted.