Repository navigation
Timezone issue - error while creating mount source path #779
Description
Description
I am trying to launch the Immich app on my Mac Mini. It used to work fine until after a reboot and now I get this error when I run 'docker compose up -d'.
Error response from daemon: error while creating mount source path '/host_mnt/private/var/db/timezone/tz/2023c.1.0/zoneinfo/Australia/Brisbane': mkdir /host_mnt/private/var/db/timezone/tz/2023c.1.0: operation not permitted
This folder does not exist on my Mac however I do have the following similar folder:
/var/db/timezone/tz/2023d.1.0
Notice the different characters 'c' and 'd'.
I am at a total loss as to how to fix this. Only a reboot where possibly MacOS was updated or Docker was updated. Sorry I cannot recall which.
I am running on a Mac Mini with Catalina 10.15.7
Reproduce
docker compose up -d
Expected behavior
It should run the Immich app as it did previously. There were no updates to Immich.
docker version
Client:
Cloud integration: v1.0.29
Version: 20.10.21
API version: 1.41
Go version: go1.18.7
Git commit: baeda1f
Built: Tue Oct 25 18:01:18 2022
OS/Arch: darwin/amd64
Context: default
Experimental: true
Server: Docker Desktop 4.15.0 (93002)
Engine:
Version: 20.10.21
API version: 1.41 (minimum version 1.12)
Go version: go1.18.7
Git commit: 3056208
Built: Tue Oct 25 18:00:19 2022
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.10
GitCommit: 770bd0108c32f3fb5c73ae1264f7e503fe7b2661
runc:
Version: 1.1.4
GitCommit: v1.1.4-0-g5fd4c4d
docker-init:
Version: 0.19.0
GitCommit: de40ad0docker info
Client:
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc., v0.9.1)
compose: Docker Compose (Docker Inc., v2.13.0)
dev: Docker Dev Environments (Docker Inc., v0.0.5)
extension: Manages Docker extensions (Docker Inc., v0.2.16)
sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc., 0.6.0)
scan: Docker Scan (Docker Inc., v0.22.0)
Server:
Containers: 6
Running: 4
Paused: 0
Stopped: 2
Images: 46
Server Version: 20.10.21
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 770bd0108c32f3fb5c73ae1264f7e503fe7b2661
runc version: v1.1.4-0-g5fd4c4d
init version: de40ad0
Security Options:
seccomp
Profile: default
cgroupns
Kernel Version: 5.15.49-linuxkit
Operating System: Docker Desktop
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.675GiB
Name: docker-desktop
ID: NOQX:BB7Z:YPWA:LUSD:AA76:MTQT:EDLS:STVX:RGNV:RZ2V:HDXW:VHJJ
Docker Root Dir: /var/lib/docker
Debug Mode: false
HTTP Proxy: http.docker.internal:3128
HTTPS Proxy: http.docker.internal:3128
No Proxy: hubproxy.docker.internal
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
hubproxy.docker.internal:5000
127.0.0.0/8
Live Restore Enabled: falseDiagnostics ID
48AFEE4A-AFBE-4DB4-8E06-DC06BE259419/20240214121252
Additional Info
No response
Activity
qiankun1024 commentedon Feb 18, 2024
Hi, I encountered the same problem, has the problem been solved？
sdetweil commentedon Feb 23, 2024
also encountering
eulmour commentedon Feb 26, 2024
same
dgageot commentedon Feb 26, 2024
I can't reproduce on Docker Desktop 4.28.0. Either it's fixed or I'm not doing the same things as you. I followed the steps here: https://immich.app/docs/install/docker-compose
sdetweil commentedon Feb 26, 2024
on Mac I had to stop the docker engine and restart, then it was ok
dgageot commentedon Feb 28, 2024
I'm going to close this one since it seems to be a transient issue. Feel free to reopen another one and ping me if you can't solve it by restarting Docker Desktop or if you have to restart it multiple times.
gvdevx commentedon Mar 12, 2024
I still have the issue as stated. Nothing has changed from restarting Docker or rebooting the machine.
How can I make it point to a different timezone folder? I am guessing this is the issue. Would really appreciate some help with this.
gvdevx commentedon Mar 12, 2024
You also mentioned you used Docker 4.28. I am running Catalina and can only use 4.15. I just do not understand why after months and months it just stopped working with the original error. Was hoping somebody who knows about Mac would be able to help out.
YI-- commentedon Mar 14, 2024
macOS: 12.7.2 Intel
Docker Desktop : 4.28.0
error:
Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting "/host_mnt/Users/xxx/Downloads/test/nginx.conf" to rootfs at "/etc/nginx/nginx.conf": mount /host_mnt/Users/xxx/Downloads/test/nginx.conf:/etc/nginx/nginx.conf (via /proc/self/fd/6), flags: 0x5000: not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected typedocker-compose eg :
No matter whether you use relative or absolute paths, there will always be a host_mnt root.
docker version:
docker info :
This problem has appeared multiple times in the past, and each time it has been accompanied by a fix, but the problem has never been completely solved.
Is there a more comprehensive solution to this? Thank you @dgageot
lanceweber commentedon Mar 28, 2024
I had this problem with my sabnzbd container, I changed the compose as follows and it's working now:
gvdevx commentedon Mar 28, 2024
Thank you. Yes, this has fixed the issue!
hari-dev06 commentedon Jan 14, 2025
where do i change this?
Roninleal commentedon Mar 14, 2025
I'm having this exact issue, the folder I have is 2025a.1.0, but it's like docker attempts to create a folder named 2024a.1.0.
I've tried the above solution without luck and I've also tried redirecting the localtime file. I've done different tz values in the .env file I've changed docker-compose yaml to the newest available in the repository, really nothing works. I'm not sure what is to blame but I assume it's Docker that's misbehaving.
If anyone can help out/shed some light that would be great!
Daredevll commentedon Mar 17, 2025
I'm also hitting that issue. This shouldn't actually be closed
gvdevx commentedon Mar 17, 2025
This was solved but unfortunately it has also come back for me too. Looks like over the last couple of days it has started happening for a few people.
Roninleal commentedon Mar 17, 2025
So it's a problem with docker. I removed it and reinstalled docker, but then I somehow broke my postgres database and started getting an error where database couldn't be reached or something, I tried to restore the database from a backup and had issues. The timezones error went away though, so I saved my photos started fresh and re-uploaded everything.
Almost 100% sure it's docker, maybe a downgrade is the answer without hurting the files?
gvdevx commentedon Mar 17, 2025
OK, I had to re-apply the above fix. For whatever reason my docker-compose.yaml went back to showing the original line again, with the :ro . Removing :ro fixes the issue for me.
antman2 commentedon May 22, 2025
Consider very carefully removing the read-only flag from your
/etc/localtimemount. Instead I chose to comment out that mount and add a TZ environment variable in its place, e.g.:Or from a docker run line,
... -e TZ=Australia/Sydney ....maxgdn commentedon Jul 9, 2025
This worked and is better than modifying the
:rothanks!progenitor-amborella commentedon Jun 18, 2026
My
/Private/var/db/timezone/tzdirectory changed from the expected2025.c.1.0to2026.b.1.0.This followed with a
docker compose up -dworked perfect! I was able to put:roback after the bringing the container up the first time.Cheers.
openSourcerer9000 commentedon Oct 22, 2026
Definitely still not fixed