Resources widget doesn't show disk space despite volumes being mapped correctly

[Kribensisis]

Description

Hi. I'm hoping to figure this out as I've never been able to solve it. Here are the details.

Using the Homepage Resources widget (in the top bar) I can't get disk space to appear, despite my volumes being mapped correctly and being able to see them in the Homepage Docker container. Glances works fine but is missing some stuff like labels that I'd like to add.

On a Synology NAS, I have three volumes: my RAID and two NVMe drives. A df shows they're mounted on volume1 volume2 and volume3.

In the Homepage docker-compose:

    volumes:
      - /volume1:/mnt/volume1
      - /volume2:/mnt/volume2
      - /volume3:/mnt/volume3

In widgets.yaml:

- resources:
    disk:
      - /mnt/volume1
      - /mnt/volume2
      - /mnt/volume3

The widgets appear, but they're empty:

The paths seem to be correct, since if I change the first volume to, say, volume21, I get this:

Should I try anything else before reporting a bug? Maybe I'm looking right past something and not seeing it? Thanks!

homepage version

v0.9.5

Installation method

Docker

Configuration

No response

Container Logs

No response

Browser Logs

No response

Troubleshooting

I've extensively troubleshooted this on and off since starting to use Homepage.

[Kribensisis]

@shamoon, might you know the cause of this?

[shamoon]

Does the API call (eg look at browser network tab) ever return anything (if so, what)?

[Kribensisis]

Does the API call (eg look at browser network tab) ever return anything (if so, what)?

Ugh. I didn't think of that. Filtering for only volume 1, I see GETs that return 200 and 304. The HAR file is enormous, but here are two snippets:

        "response": {
          "status": 304,
          "statusText": "Not Modified",
          "httpVersion": "http/1.1",
          "headers": [
            {
              "name": "Date",
              "value": "Wed, 31 Jul 2024 23:23:31 GMT"
            }

and

        "response": {
          "status": 200,
          "statusText": "OK",
          "httpVersion": "HTTP/1.1",
          "headers": [
            {
              "name": "Connection",
              "value": "keep-alive"
            }

Also, the volume mapping isn't what I'm using (typo). It's:

    volumes:
      - /volume1:/mnt/volume1
      - /volume2:/mnt/volume2
      - /volume3:/mnt/volume3

Weird issue.

[shamoon]

What is the actual data returned? not the headers/status

[Kribensisis]

What is the actual data returned? not the headers/status

Oops. It's empty: {}.

[shamoon]

Yea it's hard for me to say but seems like this is coming from an issue with systeminformation getting the disk info. The homepage side of it is extremely simple, we just call si.fsSize() and then filter for the target disk:

homepage/src/pages/api/widgets/resources.js

Lines 25 to 29 in 00a251f

	const fsSize = await si.fsSize();
	return res.status(200).json({
	drive: fsSize.find((fs) => fs.mount === target) ?? fsSize.find((fs) => fs.mount === "/"),
	});

systeminformation is a pretty active project, you may want to have a look over there: https://github.com/sebhildebrandt/systeminformation

[shamoon]

sebhildebrandt/systeminformation#883

[Kribensisis]

sebhildebrandt/systeminformation#883

Thanks. I wish there was something that could be done, but I'll investigate over there. This thread will be good to keep around to indicate the Resources widget doesn't alway work. Maybe this gets noted as a known issue in the Homepage docs? That could save folks some time.

There are no discussions in that project and I don't know that it's a bug in their project, so how should I tell them about this?

[Kribensisis]

@shamoon can you give me any details on why this isn't working that I can offer over on that project when investigating? For the issue you linked above, note that only one of the volumes that doesn't work is a btrfs RAID, the others are just normal single-disk btrfs volumes.

Do you plan to add this to the Homepage docs so users know they can't get disk space on btrfs volumes (if that's what you're saying the issue is?)

[Kribensisis]

Removing this comment. It was rude, and I apologize.

[Kribensisis]

I see you're frustrated and didn't set out to cause that, so my apologies. But as I said above, the issue you linked was with btrfs raids, while my issue includes btrfs disks that aren't raids. You never replied and I couldn't have known you updated the docs.

Checking now, I see you added this:

The resources widget primarily relies on a popular tool called systeminformation. Thus, any limitiations of that software apply, for example, BRTFS RAID is not supported for the disk usage. In this case users may want to use the glances widget instead.

But, that doesn't explain my issue as I have four btrfs volumes and only one of them is a raid. All of them show empty on disk space despite being mapped correctly. As we discovered, that's because they're sending nothing in the API response.

As I mentioned in my now-deleted docs bug, I've been a software tech writer for 15+ years and devs investigate stuff like this. It's a weird and irritating issue, but I'm not doing anything non-standard, so it's not an edge case. If I mapped the volumes wrong, nobody's pointing that out.

Also, just to say it again, I do respectfully think it's unfortunate you're advising end users of your (really awesome) project to go investigate your backend integrations. I don't think it's our place to do that, even if this is a self-hosted app you're not getting paid to develop.

Happy to provide any further detail. I'd never discount the possibility that I made an error, but unless you choose to delete this thread, I feel it should stick around so we can investigate this more. And maybe figure it out six months from now, based on new info.

[shamoon]

Sorry I missed the part about not all volumes being btrtfs.

In general, with normal disks, it is extremely rare (based on reports) that this doesn't work so it probably is a config issue. If you open a shell in the container and type df what does it say?

[Kribensisis]

No worries at all. Sorry for creating a docs bug, and also for being snarky and tagging the last dev. Super-aggravating. I should know more than most how hard stuff like this is to troubleshoot.

This is the df from inside my Homepage container (non-relevant volumes removed):

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/cachedev_2
                     11220937608 4501046968 6719890640  40% /
tmpfs                    65536         0     65536   0% /dev
tmpfs                  9132100         0   9132100   0% /sys/fs/cgroup
shm                      65536         0     65536   0% /dev/shm
/dev/mapper/cachedev_0
                     1864284244 535995388 1328288856  29% /mnt/volume3
/dev/usb1p1          7751364748 4400775876 3350470088  57% /mnt/backup
/dev/mapper/cachedev_2
                     11220937608 4501046968 6719890640  40% /mnt/volume1
0b6e0bf2928751431ec544e396619e0d6becd91761032a621b18d2b7dc8129d7/mnt/volume3
/dev/mapper/cachedev_1
                     458018000 138753176 319264824  30% /mnt/volume2

[shamoon]

according to that your homepage disks config should be /mnt/volume1 etc. In docker compose the right side is where a mapping shows up inside a container.

this looks different than your original post so I guess that’s the confusion

[Kribensisis]

Yup, I just edited my original post as it showed the wrong mappings! If I put this in widgets.yaml:

- resources:
    label: Storage
    disk:
       - /mnt/volume1
       - /mnt/volume2
       - /mnt/volume3
       - /mnt/backup 

Those volumes do show up on Homepage, but they're empty and the API response is {}.

[shamoon]

The /dev/mapper/cachedev_0 thing is very suspicious it may just be something about the drives / how they’re mounted

[shamoon]

I am curious.

If you wait for this to finish (~20 min from now): https://github.com/gethomepage/homepage/actions/runs/10393382406 and then try pulling the :main docker tag and set LOG_LEVEL=debug the resources widget will now log the data its getting from systeminformation. Let me know what it says.

[Kribensisis]

Sorry, late reply as I was away and doing this on mobile was quite fiddly! The relevant entries seem to be:

[2024-08-18T22:35:51.977Z] debug: <resources> fsSize: []
[2024-08-18T22:35:52.044Z] debug: No containers were found with homepage labels.

The first one appears repeatedly when I start the container. I can browse the volumes from the shell as well.

Here's what it looks like on Homepage and if I open a shell in the container:

I won't lose any sleep. If this is just one of those things, thanks for taking a look!

[shamoon]

Well this really does point to systeminformation, it’s quite literally returning nothing (that empty array []) for the disks. So either there’s something specific about your setup (some restrictions in docker, somewhere else) or an issue in si

[JMOdero]

The first one appears repeatedly when I start the container. I can browse the volumes from the shell as well.

Here's what it looks like on Homepage and if I open a shell in the container:

Add me to the list. I was getting a number for awhile, but it didn't look right. Then all of a sudden BLANK. I thought I changed something, but now that systeminformation has been mentioned I found this...

Because the order of lines from df command isn't as reliable, if you end up in a situation where a same type and fs but different mount point, it would be filtered out here.

Random order can be observed in these screenshots taken before and after rerunning container

On my server I see the following...

Blank.

But when I run df inside the homepage container I see the mount I am interested in.

I originally had...

- resources:
    cpu: true
    memory: true
    disk: /

and switched when it went blank. Now I have this...

- resources:
    cpu: true
    memory: true
    disk: /app/config

Still blank.

/ and /app/config currently show as blank. If I enter an invalid mount I get an error. So / and /app/config seem in some way "valid," but they currently come up blank.

Given the discussions over on the systeminformation forum I think the problem is over there. I'm surprised more people haven't mentioned this issue.

My setup...

M1 Mac mini
Asahi Remix 40 (Server Edition) bare metal
6.9.12-401.asahi.fc40.aarch64+16k
SELinux (enforcing)
mount is a USB HDD
btrfs (not RAID)

Homepage v0.9.6 (805f119, Aug 11, 2024)
Podman 5.2.2
Portainer CE 2.21.0 (rootless)

[paulsybrandy]

Hey, so I have a similar issue with Windows. I use npm to run Homepage and I have not encountered too many issues but from day 1 I have not been able to pull up any of my drives (internal or external). It states to use the mount point given by df which I did once running df on git bash for every drive I have yet always get an API Error. Strangely though, while the other services are still loading, it looks exactly as yours did, not giving any info, just a "-" where the data would be and then once all of the other services are done loading, it goes straight to an API Error. Never could figure out what was causing it to happen.

While other things are loading:

After everything else is done loading:

EDIT: Also, I never could get Finnhub to work either 🥺

[MattBodey]

I had the same issue and it turned out to be a permissions issue with the user my homepage docker container was running under.
A quick way to check is to remove any PUID/PGID setting in your docker container and see if the disk resource works.
Then it's a case of checking your docker user permissions

[paulsybrandy]

But I am running mine using npm not docker. Plus, even if I was, my user account is the primary user account on this machine with full administrator access.

EDIT: I would try it with Docker but I have no idea where my config files would go that I already have set up :(