If Immich keeps reporting free space from the ZimaOS system SSD even after you add a larger HDD, the important question is which host directory is actually bound to Immich's upload/storage mount. In the April 2026 community thread, the original user ran Immich 2.7.4 on a 250 GB system SSD and wanted photos on a 1 TB HDD. Repeatedly changing the path after installation caused unhealthy containers or startup failures.
The source thread produced several different outcomes. One user succeeded after a clean reinstall plus a custom YAML. The original author ultimately reported success only after choosing the HDD storage path before installing Immich. A later reply connected some startup failures to Immich's storage-integrity checks. Current upstream Immich documentation has also changed since version 2.7.4, so the exact container path in this historical ZimaOS package should not be copied into every current Immich deployment.
What the Original Immich 2.7.4 Setup Used
The community instructions showed this historical mapping:
Host: /DATA/Gallery/immich
Container: /usr/src/app/uploadThe first recommendation was to change only the host side and preserve the container path. For example, a secondary drive might be exposed through a ZimaOS host path while Immich still sees the expected internal upload directory.
Why Simply Changing the Host Path Did Not Work for Everyone
Several users tried replacing the default host path after Immich had already initialized. Some received an unhealthy-container state, some saw a read-only filesystem error, and others found that the app still reported the system drive.
That means this thread does not support a universal claim that “edit one volume and restart” always works. Immich persists database state and storage-integrity markers, and changing a bind mount after initialization can make the new directory inconsistent with the state Immich expects.
The Original Author's Confirmed Working Approach
After several failed attempts, Solid returned on April 19 and said the working approach was to perform a clean install and change the installation/storage path to the 1 TB HDD before the Immich installation initialized.
A Second User Confirmed a Clean-Reinstall and Custom-YAML Path
Another participant, scott492010, removed the failed installation, preserved existing photos, deleted the stale Immich AppData/database state, reinstalled, then used the custom YAML shared in the thread. They explicitly confirmed that the new setup worked.
Do not delete AppData or the Immich database casually. That community procedure was used on a broken/test installation. If the library contains important metadata, users, albums, or uploaded assets, back up both the database and photo storage before rebuilding.
Historical ZimaOS Path: /DATA/.media/...
The thread experimented with external-drive paths such as:
/DATA/.media/Elements/Photos
/DATA/.media/Elements/Photos/uploadThese examples were specific to the drives and ZimaOS path layout in that discussion. Do not copy the name Elements or assume every drive appears at the same host path. Use the actual path shown by the current ZimaOS Files/app settings.
Current Immich Uses a Different Upstream Storage Layout
Current upstream Immich Docker Compose documentation uses UPLOAD_LOCATION on the host and mounts it to /data in the current Compose template. That differs from the historical ZimaOS Immich 2.7.4 mapping to /usr/src/app/upload.
See current Immich Docker Compose documentation.
This is a version boundary, not a contradiction. If you use a ZimaOS App Store package, preserve the container destination that the current package defines. If you manage upstream Compose yourself, follow the current upstream template.
Current Immich Guidance for Custom File Locations
Immich now has a dedicated Files Custom Locations guide. It recommends changing host-side locations deliberately and moving the corresponding existing files so Immich continues to find them.
Immich also warns against splitting upload/ and library/ into separate bind mounts on the same device. For a new layout, follow the current storage model rather than reconstructing the 2026 community YAML line by line.
Why Missing .immich Files Can Stop Startup
A July 2026 reply in the thread identified errors such as:
ENOENT: no such file or directory
.../encoded-video/.immichCurrent Immich System Integrity documentation confirms that hidden .immich files are mount markers used to detect incorrect permissions or missing/replaced storage mounts.
The forum reply suggested manually creating the expected folders and marker files. Current upstream documentation is more cautious: marker files generally should not be manually created or deleted except in specific recovery situations. If the mount changed unexpectedly, correct the mount first. Manually recreating a marker is appropriate only when you have verified why it is missing.
Do Not Use chmod 777 as the Default Permission Fix
The final community reply also used:
sudo chmod -R 777 /DATA/Main-Storage/immichThis grants every local user/process broad write access. It may remove a permission barrier, but it is not the preferred permanent permission model. Identify the UID/GID and storage permissions expected by the installed Immich package instead.
Keep the PostgreSQL Database on a Suitable Filesystem
Moving photo assets to a large HDD does not mean every Immich component should live there. Current Immich requirements say the PostgreSQL database should ideally live on local SSD storage and requires a filesystem with normal Unix ownership/permission semantics; NTFS and exFAT are not supported for the database data directory.
See Immich installation requirements.
This means a reasonable architecture can keep the Immich database/app state on reliable SSD storage while placing the much larger photo/video upload location on a suitable secondary disk.
Back Up Before Rebuilding or Moving Existing Immich Data
Current Immich documentation recommends protecting both the database and filesystem assets. A database backup alone does not contain the original photos and videos.
Immich Backup and Restore guide
Safer Troubleshooting Order
- Identify the exact Immich package/version installed in ZimaOS.
- Record the current host-to-container upload mapping.
- Back up important photos and the Immich database before changing an existing install.
- For a fresh installation, choose the intended large-storage host path before first initialization when the ZimaOS package allows it.
- Preserve the container-side path defined by that package.
- If the app becomes unhealthy, read the Immich logs and look for permission or storage-integrity errors.
- Verify the new host folder is writable by the Immich container identity.
- If logs mention missing
.immichmarkers, verify the mount and directory structure before manually creating files. - Avoid
chmod 777as a permanent fix.
Immich System Storage FAQ
Why does Immich still show my system SSD capacity?
The active upload bind mount may still point to system storage, or the changed mount may not have initialized successfully. Verify the actual host-to-container mapping used by the running server.
Did the original author solve it?
Yes. Solid reported that a clean install with the HDD path selected before installation worked after post-install changes had failed.
Should I copy /usr/src/app/upload into a new Immich install?
Not blindly. That was the container path in the historical ZimaOS Immich 2.7.4 package. Current upstream Immich Compose uses /data. Follow the package/version you actually run.
Should I manually create .immich files?
Only after confirming why they are missing. Current Immich documentation says these markers normally should not be manually created or deleted except in specific recovery cases.
Can I put the database on an exFAT USB drive?
Current Immich requirements do not support exFAT/NTFS for the PostgreSQL data directory. Keep the database on a suitable local filesystem and move photo assets separately if needed.
