Immich docker fails with EACCES on mkdir /photos/library after having changed the owner of /photos to 911:1001
Closed this issue · 2 comments
Hi, I'm a linux noob and am trying to host an immich docker instance on nixos. My issue is that the immich container seems to change the owner of the "/photos/library" directory to a nonsensical value when started, and then complains about not having access to the very same directory. This is an error from the docker logs (very similar to #292):
Error: EACCES: permission denied, mkdir '/photos/library'
at mkdirSync (node:fs:1372:26)
at StorageRepository.mkdirSync (/app/immich/server/dist/repositories/storage.repository.js:122:37)
at StorageService.onBootstrapEvent (/app/immich/server/dist/services/storage.service.js:32:32)
at EventRepository.emit (/app/immich/server/dist/repositories/event.repository.js:73:19)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async ApiModule.onModuleInit (/app/immich/server/dist/app.module.js:68:9)
at async callModuleInitHook (/app/immich/server/node_modules/@nestjs/core/hooks/on-module-init.hook.js:51:9)
at async NestApplication.callInitHook (/app/immich/server/node_modules/@nestjs/core/nest-application-context.js:223:13)
at async NestApplication.init (/app/immich/server/node_modules/@nestjs/core/nest-application.js:100:9)
at async NestApplication.listen (/app/immich/server/node_modules/@nestjs/core/nest-application.js:169:33) {
errno: -13,
code: 'EACCES',
syscall: 'mkdir',
path: '/photos/library'
}
... and many more of these ...
The scenario is this: I have created an immich directory (owner root:root), and in that there is a config directory and a photos directory (owners for both is 1000:100 /a.k.a. simon:users (simon is my user)). If I start the immich docker container, the owner of the photos directory changes to 911:1001 instantly. I don't even think the uid 911 belongs to a user. If I take a look at the folder permissions using a file explorer, it doesn't display a username or group name at all as the owner.
This is how I defined the immich docker container (I'm on nixos, and this is done via a nixos configuration file):
virtualisation.oci-containers.containers = {
immich = {
autoStart = false;
image = "ghcr.io/imagegenius/immich:1.108.0";
volumes = [
"/mnt/data-partition/stuff-that-is-being-backed-up/immich/config:/config"
"/mnt/data-partition/stuff-that-is-being-backed-up/immich/photos:/photos"
"/mnt/data-partition/stuff-that-is-being-backed-up/immich/config/machine-learning:/config/machine-learning"
];
ports = [ "2283:8080" ];
environment = {
PUID = "1000";
PGID = "100";
TZ = "Europe/Berlin"; # Change this to your timezone
DB_HOSTNAME = "postgres14";
DB_USERNAME = "postgres";
DB_PASSWORD = "postgres";
DB_DATABASE_NAME = "immich";
REDIS_HOSTNAME = "redis";
};
extraOptions = [ "--network=immich-net" ];
# extraOptions = [ "--network=immich-net" "--gpus=all" ];
};
My expectation is that, since PUID is 1000 and PGID is 100, the immich container should create directories and files exactly as I do and not change the owner to 911:1001.
This is what a call to ls looks like before the immich container is started:
[simon@nixos:~]$ ls -l /mnt/data-partition/stuff-that-is-being-backed-up/immich/
total 12
drwxr-xr-x 3 simon users 4096 14. Aug 15:01 config
drwx------ 20 999 root 4096 14. Aug 15:02 pgdata
drwxr-xr-x 2 simon users 4096 14. Aug 15:01 photos
This is what a call to ls looks like after the immich container is started:
[simon@nixos:~]$ ls -l /mnt/data-partition/stuff-that-is-being-backed-up/immich/
total 12
drwxr-xr-x 3 simon users 4096 14. Aug 15:01 config
drwx------ 20 999 root 4096 14. Aug 15:02 pgdata
drwxr-xr-x 2 911 1001 4096 14. Aug 15:01 photos
I do not understand why this happens and have run out of ideas to try and as I am not very knowledgeable about nixos, immich and linux in general, any help is appreciated!
whats the output of id abc
and printenv
within the container? have you tried using the latest image?
The output of id abc looked like this:
uid=1000(abc) gid=100(users) groups=100(users)
Updating the container to 1.112.1 fixed it! Sorry that I didn't try this sooner. I didn't find anything related in the changelog and thought the error was on my side because it had worked before. But now it's all good!