immich-app/immich
1
0
Fork 0
mirror of https://github.com/immich-app/immich.git synced 2026-02-05 00:30:57 +03:00
Code Issues 16 Packages Projects Releases 10 Wiki Activity

[BUG] Report total/free space based only on the library sub-path, or a sum of all sub-paths #857

New Issue
Closed
opened 2026-02-04 23:04:20 +03:00 by OVERLORD · 3 comments
OVERLORD commented 2026-02-04 23:04:20 +03:00
Owner
Copy Link

Originally created by @oblivioncth on GitHub (May 17, 2023).

The bug

I debated submitting this as a bug vs. feature request as I'm sure the current behavior is expected; however, with recent changes I think this borders on being an issue rather than a feature.

The tl;dr is that user's taking advantage of the new storage structure to mount the sub-folders on different filesystems now will have inaccurate total/used space reported in the web UI.

I'm running Immich as a chart via TrueNAS SCALE so I can't provide setup information in the standard format, but of course am happy to provide whatever details I can. I can also assure you that this issue is a general issue that should apply to all deployments of Immich regardless of their platform.

This is related to the recent changes in which Immich's storage structure was re-arranged to allow for servers to provide the different media type sub-paths as mounts that reside on different physical storage.

In my setup, the primary pod runs on a dataset that is roughly 1.6TB in size, but I also have a dataset I want to use for the library path that is 6TB and resides on a different pool.

In previous versions of Immich, one would set the primary UPLOAD_LOCATION path directly, which in the TrueNAS SCALE chart is /usr/src/app/upload. Because of this I used the 6TB dataset for everything, so the chart would mount it to that path and everything would be stored under the old structure. I believe that Immich currently queries this specific directory to determine it's total space, as this resulted in total/free space being reported correctly in the UI as 6TB.

Now with the new path structure, I split my mounts so that the 6TB dataset is used for library only, while profile, thumbs, upload, and encoded-video are all their own datasets that are 256GB in size. With this setup, Immich reports my total space as 1.6TB, because it's still checking the total size of the filesystem that contains root "upload" directory, not being aware that the folders under it might be mounts from other filesystems.

image

Additionally, because of this as I add files to my library the reported used space does not increase.

To summarize, both the root upload folder and all of it's sub-folders in my setup are on different filesystems (as all of the sub-folders are mounted). If I use df -Ph . | tail -1 | awk '{print $2}' within each of them to check total space available on disk I see the following:

/user/src/app/
└── upload/            | 1.6T
    ├── encoded-video  | 256G
    ├── library        | 6T
    ├── profile        | 256G
    ├── thumbs         | 256G
    └── upload         | 256G

As I said, Immich is currently basing storage usage off the filesystem that the root upload folder resides on.

Instead I think that it should either:

  1. Determine used/total space from the upload/library path since that will likely constitute the most significant portion of a user's storage (and is the most "primary" storage location)
  2. Report the sum of the used/total space on all 5 of the sub-paths within that folder, so in this case
    256G + 6T + 256G + 256G + 256G = 7T

Either of those options would provide a much more accurate representation of storage usage than the UI currently shows.

The OS that Immich Server is running on

TrueNAS SCALE

Version of Immich Server

v1.55.1

Version of Immich Mobile App

N/A

Platform with the issue

  • Server
  • Web
  • Mobile

Your docker-compose.yml content

N/A

Your .env content

N/A

Reproduction steps

1) Use mounts from different filesystems for the immich storage paths
2) Observe inaccurate (or at least misleading) total space shown in the web UI

Additional information

No response

Originally created by @oblivioncth on GitHub (May 17, 2023). ### The bug I debated submitting this as a bug vs. feature request as I'm sure the current behavior is expected; however, with recent changes I think this borders on being an issue rather than a feature. **The tl;dr is that user's taking advantage of the new storage structure to mount the sub-folders on different filesystems now will have inaccurate total/used space reported in the web UI.** I'm running Immich as a chart via TrueNAS SCALE so I can't provide setup information in the standard format, but of course am happy to provide whatever details I can. I can also assure you that this issue is a general issue that should apply to all deployments of Immich regardless of their platform. This is related to the recent changes in which Immich's storage structure was re-arranged to allow for servers to provide the different media type sub-paths as mounts that reside on different physical storage. In my setup, the primary pod runs on a dataset that is roughly 1.6TB in size, but I also have a dataset I want to use for the `library` path that is 6TB and resides on a different pool. In previous versions of Immich, one would set the primary UPLOAD_LOCATION path directly, which in the TrueNAS SCALE chart is `/usr/src/app/upload`. Because of this I used the 6TB dataset for everything, so the chart would mount it to that path and everything would be stored under the old structure. I believe that Immich currently queries this specific directory to determine it's total space, as this resulted in total/free space being reported correctly in the UI as 6TB. Now with the new path structure, I split my mounts so that the 6TB dataset is used for `library` only, while `profile`, `thumbs`, `upload`, and `encoded-video` are all their own datasets that are 256GB in size. With this setup, Immich reports my total space as 1.6TB, because it's still checking the total size of the filesystem that contains root "upload" directory, not being aware that the folders under it might be mounts from other filesystems. ![image](https://github.com/immich-app/immich/assets/24661585/a701c482-6aae-4328-8a5d-041baa1300da) Additionally, because of this as I add files to my library the reported used space does not increase. To summarize, both the root upload folder and all of it's sub-folders in my setup are on different filesystems (as all of the sub-folders are mounted). If I use `df -Ph . | tail -1 | awk '{print $2}'` within each of them to check total space available on disk I see the following: ``` /user/src/app/ └── upload/ | 1.6T ├── encoded-video | 256G ├── library | 6T ├── profile | 256G ├── thumbs | 256G └── upload | 256G ``` As I said, Immich is currently basing storage usage off the filesystem that the root upload folder resides on. Instead I think that it should either: 1) Determine used/total space from the `upload/library` path since that will likely constitute the most significant portion of a user's storage (and is the most "primary" storage location) 2) Report the sum of the used/total space on all 5 of the sub-paths within that folder, so in this case `256G + 6T + 256G + 256G + 256G = 7T` Either of those options would provide a much more accurate representation of storage usage than the UI currently shows. ### The OS that Immich Server is running on TrueNAS SCALE ### Version of Immich Server v1.55.1 ### Version of Immich Mobile App N/A ### Platform with the issue - [X] Server - [X] Web - [ ] Mobile ### Your docker-compose.yml content ```YAML N/A ``` ### Your .env content ```Shell N/A ``` ### Reproduction steps ```bash 1) Use mounts from different filesystems for the immich storage paths 2) Observe inaccurate (or at least misleading) total space shown in the web UI ``` ### Additional information _No response_
OVERLORD commented 2026-02-04 23:04:28 +03:00
Author
Owner
Copy Link

@jrasm91 commented on GitHub (May 29, 2023):

Implemented option one in #2560

@jrasm91 commented on GitHub (May 29, 2023): Implemented option one in #2560
OVERLORD commented 2026-02-04 23:04:33 +03:00
Author
Owner
Copy Link

@oblivioncth commented on GitHub (May 29, 2023):

Thanks for taking care of this. I think basing the reported amount of the capacity and consumption of the library folder does make the most sense since the other directories are more-or-less secondary storage.

@oblivioncth commented on GitHub (May 29, 2023): Thanks for taking care of this. I think basing the reported amount of the capacity and consumption of the `library` folder does make the most sense since the other directories are more-or-less secondary storage.
OVERLORD commented 2026-02-04 23:04:35 +03:00
Author
Owner
Copy Link

@Emerica243 commented on GitHub (Jul 24, 2024):

Installed Immich today and experiencing same bug in overall storage space usage being shown on the main page. I am also using unique host mount points for every path\config for installation

@Emerica243 commented on GitHub (Jul 24, 2024): Installed Immich today and experiencing same bug in overall storage space usage being shown on the main page. I am also using unique host mount points for every path\config for installation
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
accessibility
changelog:enhancement
changelog:security
changelog:translation
cli
date-time
documentation
external-library
format
good first issue
needs-answer
nice to have
sharing
tech-debt
📱mobile
🖥️web
🗄️server
🧠machine-learning
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#857
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?