[Bug] Second Disk Not Found

[john-okeefe]

Description

When trying to display a widget for my second disk resource it has an API Error with 404 Not Found.

My widgets.yaml

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

- search:
    provider: duckduckgo
    target: _blank

As you can see I have a second disk mounted at /media/media

Filesystem      Size  Used Avail Use% Mounted on
dev              16G     0   16G   0% /dev
run              16G  3.2M   16G   1% /run
/dev/sdb2       211G   97G  104G  49% /
tmpfs            16G  332K   16G   1% /dev/shm
tmpfs            16G   47M   16G   1% /tmp
/dev/sda5       917G  687G  184G  79% /media/media
/dev/sdb1       300M  432K  299M   1% /boot/efi
tmpfs           3.2G   28K  3.2G   1% /run/user/1000

This is what the browser shows:

I have also tried this both with the http://192.168... url and a custom https://home.server.com url. Same issue. Docker image is running as root and regular disk: / works.

Steps to reproduce

1. Add second disk to yaml file.
2. See API Error

homepage version

v0.5.10 (e1799f1, Jan 7, 2023)

Installation method

Docker

Configuration

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

- search:
    provider: duckduckgo
    target: _blank

Container Logs

No response

Browser Logs

`

GEThttp://192.168.50.7:3000/api/widgets/resources?type=disk&target=/media/media[HTTP/1.1 404 Not Found 6ms]

  |   -- | -- GET | http://192.168.50.7:3000/api/widgets/resources?type=disk&target=/media/media

`

Other

No response

Before submitting, I have made sure to

• [X] Check the documentation
• [X] Follow the troubleshooting guide (please include output above if applicable).
• [X] Search existing issues and discussions.

shamoon commented 1 year ago

I use two disks without issue, as do many. Im not sure if this is the issue, but wonder if your yaml should look like

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

Have you tried recreating the container?

john-okeefe commented 1 year ago

I have restructured my widgets.yaml to look like:

---
# For configuration options and examples, please see:
# https://gethomepage.dev/en/configs/widgets

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

- search:
    provider: duckduckgo
    target: _blank

- datetime:
    text_size: md
    format:
        dateStyle: short
        timeStyle: short
        hour12: true

- openweathermap:
    units: imperial
    apiKey: <apiKey>
    cache: 5

I have tried destroying and restarting the docker container. Still not working.

shamoon commented 1 year ago

And what does your compose file look like?

slsnow commented 1 year ago

I don't want to hijack the issue, but I believe I'm dealing with the same issue. Mine is happening on an 11T software raid mounted at "/data". I'm wondering if the size is the problem, it being a Raid, or something else.

- resources:
    label: Lightning
    cpu: true
    memory: true
    expanded: true
    disk:
      - /
      - /data

df output:

/dev/mapper/system-root  108G   52G   50G  51% /
/dev/mapper/data-data     11T  6.9T  4.1T  64% /data

Of note, the order doesn't matter for me, it fails for "data" whether you put it first or second.

The disk mounted at "/" works just fine though, as does the memory and cpu. Since the disk mounted at "/" works, that leads me to believe it's not a problem with the docker volume, or permissions.

slsnow commented 1 year ago

Again not trying to hijack anything, so we can focus on the reporter's issue (I'm not in a hurry). Just curious if his is a raid or not, and what the disk size should be showing.

shamoon commented 1 year ago

Odd. The 404 makes me think the failure is https://github.com/benphelps/homepage/blob/main/src/pages/api/widgets/resources.js#L18 but Im not aware of why that would fail and would be interesting to know if https://github.com/SunilWang/node-os-utils drive.info() works after that or not. I suppose if it correctly fails when the drive doesnt exist and succeeds eg. in this case one could argue the initial check with existsSync isnt needed.

Obviously, I cant recreate this so I cant test...

john-okeefe commented 1 year ago

@shamoon Sorry about that. Docker file below.

version: "3.3"
services:
  homepage:
    image: ghcr.io/benphelps/homepage:latest
    container_name: homepage
    environment:
      - PUID=1000
      - PGID=970
      - TZ=America/New_York
    ports:
      - 3000:3000
    volumes:
      - ./config:/app/config # Make sure your local config directory exists
      - /var/run/docker.sock:/var/run/docker.sock:ro # (optional) For docker integrations

I'm hoping/thinking I just did something wrong with the Dockerfile because I cloned the repository and launched a dev environment and it worked just fine.

@slsnow I have an SSD as / and a HDD as /media/media. No raid, or NAS storage or anything like that. All local.

shamoon commented 1 year ago

I'm assuming you left off the mounts (which is what I am curious about)?

john-okeefe commented 1 year ago

@shamoon I'm thinking that to, but I'm not sure where to mount my external inside the docker container.

shamoon commented 1 year ago

Oh, yea mate if it's not mounted to the container it doesn't work. I assumed your shell output above was from inside the container.

See https://gethomepage.dev/en/widgets/resources/

Any disk you wish to access must be mounted to your container as a volume.

Eg

    volumes:
     ...
      - /media/media:/media

(And you would just use /media)

john-okeefe commented 1 year ago

I found mnt as an empty directory so I just added the volume: /media/media:/mnt and set /mnt as the widget folder. Worked like a charm.

I'm sorry I labeled my own ignorance as a bug. Thanks for your help everyone.

shamoon commented 1 year ago

No worries, everyone’s learning 🤓

slsnow commented 1 year ago

Ahh, that did the trick for me as well. I appreciate the help.

I'd like to explain my confusion for posterity sake, haha. I thought that the container was somehow running "df -kP" on the host itself. I wasn't understanding how "overlay" works in the container. I guess inside the container there is an "overlay" device, showing mounted at "/". It looks like "overlay" shares the same disk info inside the container as the host has (at least for the root device, or probably where the docker process is running). At least it has the same output when running "df -kP".

That explains why I was still getting proper output in homepage for the "/" disk, despite never having specified "/" as a volume when creating the container.

But the "data" device won't show and isn't mounted unless you specify it when creating the container. Now after having done that, within the container docker exec -it homepage, the "df -kP' output is as expected, and homepage is showing the info as expected.

Anyways, guess I need to do some more reading on the overlay2 driver, thanks guys. Enjoy your weekend.

github-actions[bot] commented 6 months ago

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion for related concerns.

• © Githubissues.
• Githubissues is a development platform for aggregating issues.

[shamoon]

I use two disks without issue, as do many. Im not sure if this is the issue, but wonder if your yaml should look like

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

Have you tried recreating the container?

[john-okeefe]

I have restructured my widgets.yaml to look like:

---
# For configuration options and examples, please see:
# https://gethomepage.dev/en/configs/widgets

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

- search:
    provider: duckduckgo
    target: _blank

- datetime:
    text_size: md
    format:
        dateStyle: short
        timeStyle: short
        hour12: true

- openweathermap:
    units: imperial
    apiKey: <apiKey>
    cache: 5

I have tried destroying and restarting the docker container. Still not working.

[shamoon]

And what does your compose file look like?

[slsnow]

I don't want to hijack the issue, but I believe I'm dealing with the same issue. Mine is happening on an 11T software raid mounted at "/data". I'm wondering if the size is the problem, it being a Raid, or something else.

- resources:
    label: Lightning
    cpu: true
    memory: true
    expanded: true
    disk:
      - /
      - /data

df output:

/dev/mapper/system-root  108G   52G   50G  51% /
/dev/mapper/data-data     11T  6.9T  4.1T  64% /data

Of note, the order doesn't matter for me, it fails for "data" whether you put it first or second.

The disk mounted at "/" works just fine though, as does the memory and cpu. Since the disk mounted at "/" works, that leads me to believe it's not a problem with the docker volume, or permissions.

[slsnow]

Again not trying to hijack anything, so we can focus on the reporter's issue (I'm not in a hurry). Just curious if his is a raid or not, and what the disk size should be showing.

[shamoon]

Odd. The 404 makes me think the failure is https://github.com/benphelps/homepage/blob/main/src/pages/api/widgets/resources.js#L18 but Im not aware of why that would fail and would be interesting to know if https://github.com/SunilWang/node-os-utils drive.info() works after that or not. I suppose if it correctly fails when the drive doesnt exist and succeeds eg. in this case one could argue the initial check with existsSync isnt needed.

Obviously, I cant recreate this so I cant test...

[john-okeefe]

@shamoon Sorry about that. Docker file below.

version: "3.3"
services:
  homepage:
    image: ghcr.io/benphelps/homepage:latest
    container_name: homepage
    environment:
      - PUID=1000
      - PGID=970
      - TZ=America/New_York
    ports:
      - 3000:3000
    volumes:
      - ./config:/app/config # Make sure your local config directory exists
      - /var/run/docker.sock:/var/run/docker.sock:ro # (optional) For docker integrations

I'm hoping/thinking I just did something wrong with the Dockerfile because I cloned the repository and launched a dev environment and it worked just fine.

@slsnow I have an SSD as / and a HDD as /media/media. No raid, or NAS storage or anything like that. All local.

[shamoon]

I'm assuming you left off the mounts (which is what I am curious about)?

[john-okeefe]

@shamoon I'm thinking that to, but I'm not sure where to mount my external inside the docker container.

[shamoon]

Oh, yea mate if it's not mounted to the container it doesn't work. I assumed your shell output above was from inside the container.

See https://gethomepage.dev/en/widgets/resources/

Any disk you wish to access must be mounted to your container as a volume.

Eg

    volumes:
     ...
      - /media/media:/media

(And you would just use /media)

[john-okeefe]

I found mnt as an empty directory so I just added the volume: /media/media:/mnt and set /mnt as the widget folder. Worked like a charm.

I'm sorry I labeled my own ignorance as a bug. Thanks for your help everyone.

[shamoon]

No worries, everyone’s learning 🤓

[slsnow]

Ahh, that did the trick for me as well. I appreciate the help.

I'd like to explain my confusion for posterity sake, haha. I thought that the container was somehow running "df -kP" on the host itself. I wasn't understanding how "overlay" works in the container. I guess inside the container there is an "overlay" device, showing mounted at "/". It looks like "overlay" shares the same disk info inside the container as the host has (at least for the root device, or probably where the docker process is running). At least it has the same output when running "df -kP".

That explains why I was still getting proper output in homepage for the "/" disk, despite never having specified "/" as a volume when creating the container.

But the "data" device won't show and isn't mounted unless you specify it when creating the container. Now after having done that, within the container docker exec -it homepage, the "df -kP' output is as expected, and homepage is showing the info as expected.

Anyways, guess I need to do some more reading on the overlay2 driver, thanks guys. Enjoy your weekend.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion for related concerns.