Immich Creates Folders In UPLOAD_LOCATION After Deletion
Have you ever set up custom locations for your Immich data, only to find it stubbornly recreating folders in your default UPLOAD_LOCATION? You're not alone! This article dives into a peculiar issue reported by an Immich user where, despite configuring custom locations for thumbnails and encoded videos, Immich kept recreating these folders under the UPLOAD_LOCATION, even after deletion. This can lead to confusion, storage inefficiencies, and errors within your Immich setup. We'll explore the problem, the user's setup, the errors encountered, and potential solutions or workarounds.
Understanding the Issue
The core issue revolves around Immich, a self-hosted photo and video backup solution, ignoring custom-defined storage locations and instead defaulting to the UPLOAD_LOCATION for certain operations. Specifically, after setting up custom paths for derived data folders like THUMB_LOCATION and ENCODED_VIDEO_LOCATION, the user observed Immich recreating these same folders within the UPLOAD_LOCATION. Initially, these folders were empty, but after some time, Immich started generating thumbnails in the UPLOAD_LOCATION/thumbs directory, effectively bypassing the custom location. This discrepancy led to errors as Immich struggled to locate files in the expected custom locations, disrupting the normal functionality of the application. This problem highlights the importance of accurate configuration and the potential pitfalls of conflicting settings within Immich.
This issue is particularly concerning because it can lead to several problems. First, it wastes storage space by creating duplicate folders and files. Second, it can cause performance issues if the UPLOAD_LOCATION is on a slower storage medium than the custom locations. Finally, it can lead to errors and instability in the Immich application. Therefore, understanding the root cause of this issue and finding a solution is crucial for maintaining a healthy and efficient Immich setup. The following sections will delve deeper into the user's specific setup and the errors they encountered, providing a clearer picture of the problem and potential avenues for troubleshooting. We'll examine the configuration files, the logs, and the steps taken by the user to reproduce the issue, aiming to identify the underlying cause and offer practical solutions.
User's Configuration and Setup
To better understand the problem, let's examine the user's specific configuration. The user configured custom locations for derived data folders like THUMB_LOCATION, ENCODED_VIDEO_LOCATION, PROFILE_LOCATION, and BACKUP_LOCATION, as per the Immich documentation. These custom locations were set on an SSD for performance reasons, while the UPLOAD_LOCATION was likely on a different storage medium. This setup is designed to optimize Immich's performance by storing frequently accessed thumbnails and encoded videos on faster storage. The user's docker-compose.yml and .env files provide valuable insights into their setup:
Docker-Compose.yml
The docker-compose.yml file defines the services that make up the Immich application. In this case, the relevant section is the immich-server service:
services:
immich-server:
container_name: immich_server
image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
devices:
- /dev/dri:/dev/dri
volumes:
# Do not edit the next line. If you want to change the media storage location on your system, edit the value of UPLOAD_LOCATION in the .env file
- ${UPLOAD_LOCATION}:/data
- ${THUMB_LOCATION}:/data/thumbs
- ${ENCODED_VIDEO_LOCATION}:/data/encoded-video
- ${PROFILE_LOCATION}:/data/profile
- ${BACKUP_LOCATION}:/data/backups
- /share/Media/Photos:/mnt/media/photos
- /etc/localtime:/etc/localtime:ro
env_file:
- stack.env
This configuration mounts the custom locations specified in the .env file to corresponding directories within the container. For example, ${THUMB_LOCATION} is mounted to /data/thumbs inside the container. This setup is crucial for Immich to recognize and utilize the custom storage locations.
.env File
The .env file defines the environment variables used by the Immich application. The key variables in this context are:
UPLOAD_LOCATION=/share/Media/Photos
BACKUP_LOCATION=/volume1/Docker/immich-app/backups
PROFILE_LOCATION=/volume1/Docker/immich-app/profile
THUMB_LOCATION=/volume1/Docker/immich-app/thumbs
ENCODED_VIDEO_LOCATION=/volume1/Docker/immich-app/encoded-video
This file clearly defines the custom locations for various Immich data folders. The UPLOAD_LOCATION is set to /share/Media/Photos, while the other locations point to directories within /volume1/Docker/immich-app/. The discrepancy between these paths is where the potential conflict arises. Even though custom locations are specified, Immich seems to be falling back to the UPLOAD_LOCATION for certain operations, leading to the observed issue. This configuration highlights the importance of verifying that Immich correctly interprets and applies these settings.
The Errors and Their Significance
The user reported encountering specific errors in the Immich logs, which shed light on the problem. These errors indicate that Immich is attempting to access thumbnail files in the UPLOAD_LOCATION (/data/thumbs) instead of the custom THUMB_LOCATION. Let's examine the error messages:
[Nest] 25 - 12/01/2025, 5:52:03 AM ERROR [Api:PersonController~6ff33c4h] Unable to send file: Error: ENOENT: no such file or directory, access '/data/thumbs/5e242fbe-eba3-49d7-840a-fbfb0f4011ba/63/7f/637f86d3-fd73-40a1-9b73-91c502db9bc5.jpeg'
Error: ENOENT: no such file or directory, access '/data/thumbs/5e242fbe-eba3-49d7-840a-fbfb0f4011ba/63/7f/637f86d3-fd73-40a1-9b73-91c502db9bc5.jpeg'
at async access (node:internal/fs/promises:606:10)
at async sendFile (/usr/src/app/server/dist/utils/file.js:49:9)
at async PersonController.getPersonThumbnail (/usr/src/app/server/dist/controllers/person.controller.js:63:9)
This error message, ENOENT: no such file or directory, clearly indicates that Immich cannot find the requested thumbnail file in the specified path, which is under /data/thumbs. Remember, /data inside the container maps to the UPLOAD_LOCATION on the host system. This confirms that Immich is indeed looking for thumbnails in the wrong location. The error occurs within the PersonController, suggesting that it's related to displaying person thumbnails in the Immich interface.
Similar errors are reported for other thumbnail files, reinforcing the pattern:
[Nest] 25 - 12/01/2025, 5:52:03 AM ERROR [Api:PersonController~576iq2a7] Unable to send file: Error: ENOENT: no such file or directory, access '/data/thumbs/5e242fbe-eba3-49d7-840a-fbfb0f4011ba/54/d3/54d315f4-5d55-435d-b6b1-7015475d5540.jpeg'
These errors are significant because they directly impact the user experience. When Immich cannot find the thumbnails, they won't be displayed correctly in the interface, leading to a broken or incomplete view of the user's library. Furthermore, the repeated errors can put a strain on the server's resources and potentially lead to instability. Understanding these errors is crucial for diagnosing the problem and implementing effective solutions.
Potential Causes and Solutions
Several factors could contribute to Immich's behavior of recreating folders in the UPLOAD_LOCATION and generating thumbnails there, despite the custom location settings. Let's explore some potential causes and their corresponding solutions:
-
Incorrect Volume Mounts: Although the
docker-compose.ymlfile seems to define the volume mounts correctly, there might be an underlying issue with how Docker is handling these mounts. A potential solution is to double-check the paths specified in the.envfile and ensure they are accessible from within the Docker container. Verify that the user running the Immich container has the necessary permissions to access the custom locations. -
Caching or Configuration Conflicts: Immich might be caching some configuration settings that are overriding the custom locations. Clearing Immich's cache or restarting the application might resolve this issue. Another possibility is a conflict between different configuration methods. If Immich has a configuration file in addition to environment variables, ensure that the settings in both locations are consistent.
-
Bug in Immich Version: It's possible that the issue is a bug in the specific version of Immich being used (v2.3.1). Checking the Immich GitHub repository for reported issues or updates related to custom locations could provide insights. Upgrading to a newer version of Immich might include a fix for this bug.
-
File System Permissions: If the user running the Immich container does not have write permissions to the custom locations, Immich might fall back to the
UPLOAD_LOCATION. Ensure that the user has the appropriate permissions to create and modify files in theTHUMB_LOCATIONandENCODED_VIDEO_LOCATION. -
Startup Order: The order in which the Immich services start might also play a role. If the custom locations are not available when Immich first starts, it might default to the
UPLOAD_LOCATION. Try adding a dependency in thedocker-compose.ymlfile to ensure that the storage volumes are mounted before the Immich server starts.
To address this issue, the user can try the following steps:
- Double-check the volume mounts in the
docker-compose.ymlfile and the paths in the.envfile. - Verify the file system permissions for the custom locations.
- Restart the Immich container and the Docker daemon.
- Clear Immich's cache (if applicable).
- Upgrade to the latest version of Immich.
- Consult the Immich documentation and community forums for similar issues and solutions.
Conclusion
The issue of Immich recreating folders in the UPLOAD_LOCATION despite custom location settings is a frustrating one, but understanding the configuration, the errors, and potential causes can pave the way for a solution. By carefully reviewing the setup, checking file system permissions, and considering potential conflicts or bugs, users can troubleshoot this problem and ensure that Immich utilizes the custom storage locations as intended. This not only optimizes performance but also prevents storage inefficiencies and errors within the application. Remember to consult the Immich documentation and community forums for further assistance and to stay informed about updates and bug fixes. For more information on Immich and its features, you can visit the official Immich website or GitHub repository. This issue highlights the importance of diligent configuration and monitoring in self-hosted applications like Immich, ensuring a smooth and efficient user experience.
For further reading on Immich and its capabilities, you can visit the Immich Documentation for comprehensive guides and information.