[BUG] Dashy 3.0.0 not loading despite complete build

[allesauseinerhand]

[BUG] Dashy 3.0.0 not loading despite complete build

[rodalpho]

@allesauseinerhand Yes my logs end with that line.

@Lissy93 No problem, not intending to criticize! I would note the expected file and directory structure for /app/user-data/, that's what had me stalled for a minute. IE, "It should contain conf.yml as well as the fonts, img, item-icons, etc directories".

[KetaiDenwa]

Hi to everybody.
I got the exact same problem while opening Dashy without "/login". But there are two differences in my configs, I set "enableGuestAccess" to "true" and I enabled ssl with self-signed certificates, passing the 443 Port to Docker. With the "/login" link, i get to the Login page without a problem. Then I can open my Dashboard by entering my admin login data or by following the link to visit my Dashboard as a guest. Both methods are doing fine there, but I can`t open it with the normal "dashy-IP:port".

[tdeppner]

So two breaking changes on the docker image (2.1.2 -> 3.0.0) that it'd be great to have an in-built work around for, better start-up messaging around, or better documentation around these changes.

Thanks for all the work on this!

port 80 became port 8080
/app/public/conf.yml became /app/user-data/conf.yml

$ git diff services/dashy.yml
diff --git a/ansible/docker/services/dashy.yml b/ansible/docker/services/dashy.yml
index fe8f7ca..8195054 100644
--- a/ansible/docker/services/dashy.yml
+++ b/ansible/docker/services/dashy.yml
@@ -23,7 +23,8 @@
         state: started
         restart_policy: unless-stopped
         ports:
-          - '8989:80'
+          - '8989:8080'
         volumes:
-          - /root/data/dashy/config/conf.yml:/app/public/conf.yml
+          - /root/data/dashy/config/conf.yml:/app/user-data/conf.yml
           - /root/data/dashy/item-icons/:/app/public/item-icons/
+       # 2.1.2 and earlier was port 80 and conf.yml in /app/public, 3.0.0 it became 8080 and /app/user-data/conf.yml

[CrazyWolf13]

@tdeppner

It has been documented here:

#1537
#1529
And with a note on the main readme:

Let us know if we should add any guide anywhere else.

[Lissy93]

Understood. Maybe a WARN message on docker start up if /app/public/conf.yml exists that might ask if this was intended, reference this bug, encourage folks the "new" location is /app/user-data, etc?

Thanks @tdeppner - good feedback, I've implemented a build-time check in Docker that displays a lil message if there's a config issue, and for client-side issues I've made an update which will show exactly what the problem is. Both will be included when I merge #1542 later this week.

---

I'm going to close this ticket now, but if anyone is still having issues here, let me know below and I'll reopen.

[CrazyWolf13]

So I've just spun up a test vm with the default config, except I added basic auth.

When guest-acces is false, I get straight redirected to http://ip/login
When guest-acces is true I get straight to the dashboard

RAM enableGuestAccess: trueusage for me was 1.5GB with 4.5GB assigned.
CPU was 40% at max with 2 cores

So for me everything is working fine.

[Kirkland-gh]

I am still required to go to /login else I have the generic loading page with 3.0.1

I have a screenshot of my console when I load the page here

[CrazyWolf13]

Can you paste the browser console output?

How long have you waited after the error message appeared, sometimes refreshing the page also resolved the issue.

[allesauseinerhand]

Hi Tobias, thanks for looking at the issue. Here is the browser console output just logged after entering the url. It doesn't change when the error message appears. So probably no client-side problem.

[ContentMain]
ContentMain.js:5 [ContentService] document.readyState: loading
ContentMain.js:5 [ContentService.SetContentInitData] target: { TabId: 662559308, FrameId: 0}

[allesauseinerhand]

How long have you waited after the error message appeared, sometimes refreshing the page also resolved the issue.

I have waited several minutes, I did refresh (F5) and I tried in Chrome (Guest Mode) and MS Edge

[rodalpho]

I changed my config to look like yours (with my paths) and had no issues with the 3.0 changes, loaded fine. I did need to map /app/public/ inside the container to get the icons to show up properly; possibly they would work inside user-data/ also. User-data/ needs the conf.yml file, and public/ needs fonts/, img/, item-icons/, etc. The docs on the 3.0 upgrade aren't... great so this took a couple mins to figure out properly.

My volumes line:

    volumes:
     - /opt/dashy/user-data/:/app/user-data/
     - /opt/dashy/public/:/app/public/

On a side note, man, dashy takes a crazy long time to start up. My relatively simple dashboard takes 55 seconds! I'm not running a rPi4 or anything underpowered either, it's a 7500T mini-desktop with tons of RAM and free CPU.

2024-04-20T16:58:21.719069075Z  DONE  Compiled successfully in 54820ms4:58:21 PM	 

[allesauseinerhand]

@rodalpho Thank you for your time to add a solution, that worked for you. Sadly it doesn't work for me. I did now map the two volumes, but it didn't change anything with my problem.

volumes:
 - /dockerdata-fast/config/homepage/dashy_public_dir:/app/user-data
 - /dockerdata-fast/config/homepage/dashy_public_dir:/app/public

By the way, this is the content of my dashy_public_dir folder:

A question about your logs: is the last line of your log also "Check out deployment instructions at https://cli.vuejs.org/guide/deployment.html" or is it something else?

[Lissy93]

Hey @allesauseinerhand
Sorry you're having issues. It looks like your config isn't being passed to Docker correctly - If you visit [dashy-url]/conf.yml what you you see?
Maybe the issue is because initially the paths were wrong, and so the initial (and only) build happened without a config. In which case, starting fresh should resolve it.

[Lissy93]

Thanks @rodalpho

. I did need to map /app/public/ inside the container to get the icons to show up properly; possibly they would work inside user-data/ also. User-data/ needs the conf.yml file, and public/ needs fonts/, img/, item-icons/, etc.

Both /public and /user-data basically resolve to the same place. So you shouldn't need to pass both in, just put all your customized assets into user-data

---

The docs on the 3.0 upgrade aren't... great so this took a couple mins to figure out properly

Sorry about that (I'm not great at writing docs!), if you have suggestions about how I can make this clearer, I will update them :)

[rodalpho]

@Lissy93 Moving all the files I had in /app/public to /app/user-data and removing the mapping in my docker-compose broke dashy, and the app made its own public directory somehow. So I'm reverting that.

[allesauseinerhand]

Hey @allesauseinerhand Sorry you're having issues. It looks like your config isn't being passed to Docker correctly - If you visit [dashy-url]/conf.yml what you you see?

Hi @Lissy93 : Thanks for helping me with this. When I load this url, the conf.yml-file is showed in the browser as it probably should be.

But I supposed to found the reason, why it didn't work initially, which could help others with the same problem too: I use simple auth in the conf.yml:

appConfig:
  auth:
    users:
      - user: USERNAMECHANGED
        hash: HASHCHANGED
        type: admin
    enableGuestAccess: false

I now tried to enter [dashy_url]/login and then I see my dashboard. When I then enter again [dashy_url] the error is there again. So, next I went again to [dashy_url]/login, then logged out, logged in again. But even then, when I open [dashy_url], the same error comes up again. Next, I tried to delete the above auth-section in the config. But even then it doesn't work. I've at least now a workaround (entering [dashy_url]/login instead of [dashy_url]. But do you have any idea, what could be the reason for this strange behaviour?

[Lissy93]

So two breaking changes on the docker image (2.1.2 -> 3.0.0) that it'd be great to have an in-built work around for, better start-up messaging around, or better documentation around these changes.

I would have loved to be able to implement an automatic workaround for this, but it's unfortunately not possible.

---

No problem, not intending to criticize! I would note the expected file and directory structure for /app/user-data/, that's what had me stalled for a minute. IE, "It should contain conf.yml as well as the fonts, img, item-icons, etc directories".

Thanks for the feedback @rodalpho. Here are clearer docs, outlining structure of the user-data directory. Not merged yet, but will be included soon when I finish #1542

---

Just to check, is anyone still having issues getting 3.0.0 running?

[tdeppner]

I would have loved to be able to implement an automatic workaround for this, but it's unfortunately not possible.

Understood. Maybe a WARN message on docker start up if /app/public/conf.yml exists that might ask if this was intended, reference this bug, encourage folks the "new" location is /app/user-data, etc?

Just to check, is anyone still having issues getting 3.0.0 running?

It's fine for me, no concerns.

Thank you for a great product, and quick support. :)

[allesauseinerhand]

Hi Alicia

Probably my previous message about the workaround was misleading, as you thought the problem is solved now. But it is still not working the normal way: When I go to [dashy_url] I still see the same error message as I showed in the first post of this thread. Only going to [dashy_url]/login leads me to the dashboard. Do you have any idea, what the reason could be or what information I should provide to find the rootcause of the problem?

[MacLemon]

Same issue here after upgrading my installation from v2 to v3.
I'm not doing any authenication in Dashy at all. I use HTTP BASIC AUTH on my reverse proxy in front of Dashy. (Using Caddy)

Tip

I Can confirm the workaround with https://<url.to.my.dashy.instance>/login is working.

Issuse persists after completely trashing the existing container and image and recreating it from scratch to make sure everything is fully rebuilt from scratch. Hence I assume it's unrelated to upgrading from v2.

Unrelated to this issue, just a data point:
Starting the container takes several minutes and grabs 3+ vCores and over 4GB in the process during application build. About 10 Minutes after start it settles around 2.5GB RAM usage with little CPU usage when idle.

[Lissy93]

Has anyone got any browser logs of this issue? As I'm struggling to recreate it
I mean client-side logs, not server-side logs- here's how to view browser logs.

[Lissy93]

Try again now, I've pushed some updates in 3.0.1, everything should be resolved. If not, share the content of your browser logs, so I can debug further.

[CrazyWolf13]

I have a screenshot of my console when I load the page here

Could you copy+paste them?
I cannot seem to open that image.

[HakanP]

I also have to add the /login to get the gui to load. Doesn't show much in the console:

But when I add /login then it shows error 404 and then loads the page.

[Kirkland-gh]

I have a screenshot of my console when I load the page here

Could you copy+paste them? I cannot seem to open that image.

I used a screen shot to show that my console is blank of everything but a favcon.ico loading error.

[Lissy93]

@HakanP - this looks like a config issue. Could you share your config file?

@Kirkland-gh - This does look like a bug, but I'm not able to recreate it just yet, could you also share the relevant parts of your config so I can try with that?

[Kirkland-gh]

  auth:
    enableGuestAccess: false
    users: []
    enableKeycloak: true
    keycloak:
      serverUrl: https://keycloak.example.com
      realm: example-realm
      clientId: example-clientid
      legacySupport: false

[HakanP]

That "Something gone wrong...."-page is if i just go to the dashy page by ip:port.
If I then add /login then the page works and look just fine, so shouldn't be the config I think.
I also don't have any authentication enabled.

[allesauseinerhand]

Has anyone got any browser logs of this issue? As I'm struggling to recreate it I mean client-side logs, not server-side logs- here's how to view browser logs.

Attached are two logs: index.log for when visiting url (showing error screen), login.log for when visiting url/login (showing login screen). And also I attached my docker compose file and my dashy conf (shortened and masked)
index.log
login.log
docker-conf.txt
dashy_conf.txt

[Muzuwi]

I have encountered the same issue with my Dashy. Attached is my config with sections removed/masked. Auth is not enabled.

• Opening the dashboard directly (without /login) gives no logs whatsoever in the browser console, it's stuck at the main splash screen (and after a while the error message from the OP appears).
• Accessing /login opens the dashboard properly (but doesn't fix the issue - it happens again when you refresh the page). Attached browser logs from this access (masked a bit).
• Accessing /<anything that 404s> also allows access to the dashboard, with the difference that you have to click "Go back" on the 404 screen.

One thing I've noticed is that curl'ing the broken Dashy gives a broken index.html. It seems in my case the Dashy app is not being injected at all on the main / route (other than the timeout handler). On /login, I can see that the scripts/css are injected properly. Broken index.html attached.
A locally deployed, freshly pulled image of Dashy does not exhibit this behavior; that is, curling both / and /login returns the same document (with Dashy scripts present).

I can do further testing with the broken setup if required.

conf.txt
browser_logs_login.txt
broken_index.html.txt

[AyaanMAG]

Hello, I seem to be facing the same issue, I've tried incognito and opening the URL with /login does indeed bring up the dashboard which leads me to believe it's the same bug however I see a different output in my console log, this extra information may be useful. I am using Windows 10 Pro

[KetaiDenwa]

Is there allready any update on this issue? Don't want to hurry anybody, just a question out of interest.

[MacLemon]

Try again now, I've pushed some updates in 3.0.1, everything should be resolved. If not, share the content of your browser logs, so I can debug further.

The only output in my browser console:

GET
https://launch.maclemon.at/
[HTTP/2 200  9ms]

GET
https://launch.maclemon.at/loading-screen.css
[HTTP/2 200  6ms]

GET
https://launch.maclemon.at/web-icons/favicon-32x32.png
[HTTP/2 200  6ms]

Request Headers:

GET / HTTP/2
Host: launch.maclemon.at
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:125.0) Gecko/20100101 Firefox/125.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
DNT: 1
Sec-GPC: 1
Authorization: Basic cmljazpuZXZlciBnb25uYSBnaXZlIHlvdSB1cCwgbmV2ZXIgZ29ubmEgbGV0IHlvdSBkb3duCg==
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: cross-site
Pragma: no-cache
Cache-Control: no-cache
TE: trailers

Response Headers:

HTTP/2 200 
accept-ranges: bytes
alt-svc: h3=":443"; ma=2592000
cache-control: public, max-age=0
content-type: text/html; charset=UTF-8
date: Sat, 11 May 2024 20:59:31 GMT
etag: W/"789-18197f1fee0"
last-modified: Fri, 24 Jun 2022 23:00:28 GMT
server: Caddy
x-powered-by: Express
content-length: 1929
X-Firefox-Spdy: h2

I'm using Caddy as reverse proxy in front of Dashy.

Relevant section of the Caddyfile

launch.maclemon.at
{
  basicauth /* {
    rick <passphrase>
  }
  reverse_proxy dashy:8080
}

Hope this helps making the issue more easily reproducible.
Workaround with appending /login still works in 3.0.1.