Container Fails to Start with "No such file or directory" Error After Update to v1.0.1173_20-01-2025 #734
Comments
|
What happens at the start of the script during initialisation? This is when the /tmp/icloudpd folder is created. Your container is complaining that it doesn't exist. Which is odd, as it's created every time the container starts (if cannot find it) and it should also generate an error, or halt the container, if the command to create it fails. |
|
The container stopped and kept restarting while producing below log when I run with the latest version
And below is when I switched to v1.0.1096_15-01-2025
|
|
The latest version of the container performs an initialisation prior to where you have copied the log from though. It's this that I'm interested in. |
|
I've got the same issue. I thought I created an issue for that a couple days ago, but it disappeared. Here's more detail from my side (FYI, hosting on Docker on top of a Synology box): Looks like an username/rights issue? |
|
Same issue here when I updated about 5 mins ago. 4 containers out of action 😬 Synology NAS |
|
Two of you are getting:
Line 13 is simply: This is saying that it can't find the configuration file, because the ${config_file} variable does not exist/is empty. However, this is hardcoded at build time in the container. Are you overriding the variable at launch somehow? config_file="" maybe? Also, if you check this post: #736, you'll notice that the log file starts with "Initialising container..." then does all the stuff it needs to before running (ignore his error about libraries for now lol). Can you guys post this part of the log? You're all running Synology devices too, so I don't think this is a coincidence. How are you all creating your container? |
That will have been the one that was deleted because it ignored the issue template. |
|
I'm not sure where to get the log stuff before that. Synology container manager doens't show it Here's what my variables are set to
|
|
Can you check your /config volume and see if the icldoud.conf file has all these variables correctly set in it? The bit of the log I'm referring to is just the output of the /usr/local/bin/launcher.sh file. This is the first thing that the container fires up, it then calls a 2nd script to create and initialise the icloudpd.conf file, after that completes control is returned to launcher.sh and it then hands over to the 3rd script sync-icloud.sh which handles everything from there on out. Maybe your container is skipping over the first script. Where have you installed the container from? Dockerhub? I know that in the past, someone created an UnRAID template, which hardcoded a bunch of stuff and invalidated future changes. I wonder if you'd all installed from a source which I have no control over, like the UnRAID template. |
|
I have the same problem，this is the log root@DS218plus:~# docker exec -it icloudpd sync-icloud.sh --Initialise |
|
Can you grab the container log files (rather than just running the sync-icloud.sh script in the existing container)? Should be: That should have the output of the initialisation portion of when the container started. |
The output is the same... |
Here's the file (removed personal info)
Yes, installed from Docker Hub |
Yes, for the longest time I've had mine has been set to: config_file="/config/icloudpd.conf" |
|
I created a new container from scratch and got the same result |
|
Can you lost the results of a There might be a boat load of info, I just want to see what it says for command/cmd and entrypoint |
|
Below is my container inspect |
|
These bits are both wrong somehow: They should look like this: I can also see the variables are not correctly set: This is what it looks like in my inspect: The config_dir variable hasn't been set in the Dockerfile, for ages. It's been config_file for a long time now. The only variable I set at creation time is TZ, all the other variables are hardcoded into the container, and in there TZ="UTC" so I'm overriding it. You can validate that here: https://hub.docker.com/layers/boredazfcuk/icloudpd/latest/images/sha256-5cb37f7c3f124367ad561522fbbe0892f8bbd659a574d790247c1e3ada8d7fc7 (it also shows the CMD as /usr/local/bin/launcher.sh) The only thing can think is that Synology have switched the default Docker registry to something different and you're not getting the one I publish on Dockerhub. Can you recreate your container, but use docker.io/boredazfcuk/icloudpd as the image name, instead of just boredazfcuk/icloudpd? e.g.: |
|
Some progress today... Container Manager was showing an update avaialble for the image, so I updated it, but the original continer still didn't work. 
Created a new one and its working now Not sure what changed, but in Docker Hub it is showing 2 updates pushed pretty close to each other https://registry.hub.docker.com/r/boredazfcuk/icloudpd/tags 
|
Good news
That's one update. It's a list of tags. 1.0.1178_23-01-2025 is also tagged as "latest" because it is the latest version. You can tell the tags point to the same image as the digests are the same for both tags. |
|
Also now working for me, after creating a new container. Creating a new container did not do the trick for me previously. Weird. |
|
It's now working for me as well by creating a new container. Thank you! Few notes
here's my inspect from the latest version (1.0.1179_25-01-2025) for your reference. |
|
Strange, I can see you've not even prefixed the container image name with docker.io/ so literally nothing should have been different from the last time it was recreated. |
System:
Describe the bug
Expected behaviour
Actual behaviour
Debug log file
2025-01-22 22:33:01 INFO ***** boredazfcuk/icloudpd container v1.0.1173_20-01-2025 started *****
2025-01-22 22:33:01 INFO ***** For support, please go here: https://github.com/boredazfcuk/docker-icloudpd *****
2025-01-22 22:33:01 INFO Alpine Linux 3.21.2
cat: /tmp/icloudpd/python_version: No such file or directory
2025-01-22 22:33:01 INFO Python version:
cat: /tmp/icloudpd/icloudpd_version: No such file or directory
2025-01-22 22:33:01 INFO icloud-photos-downloader version:
2025-01-22 22:33:01 INFO Loading configuration from:
/usr/local/bin/sync-icloud.sh: source: line 13: can't open '': No such file or directory
2025-01-22 22:33:17 INFO ***** boredazfcuk/icloudpd container v1.0.1173_20-01-2025 started *****
2025-01-22 22:33:17 INFO ***** For support, please go here: https://github.com/boredazfcuk/docker-icloudpd *****
2025-01-22 22:33:17 INFO Alpine Linux 3.21.2
cat: /tmp/icloudpd/python_version: No such file or directory
2025-01-22 22:33:17 INFO Python version:
cat: /tmp/icloudpd/icloudpd_version: No such file or directory
2025-01-22 22:33:17 INFO icloud-photos-downloader version:
2025-01-22 22:33:17 INFO Loading configuration from:
/usr/local/bin/sync-icloud.sh: source: line 13: can't open '': No such file or directory
2025-01-22 22:33:30 INFO ***** boredazfcuk/icloudpd container v1.0.1173_20-01-2025 started *****
2025-01-22 22:33:30 INFO ***** For support, please go here: https://github.com/boredazfcuk/docker-icloudpd *****
2025-01-22 22:33:30 INFO Alpine Linux 3.21.2
cat: /tmp/icloudpd/python_version: No such file or directory
2025-01-22 22:33:30 INFO Python version:
cat: /tmp/icloudpd/icloudpd_version: No such file or directory
2025-01-22 22:33:30 INFO icloud-photos-downloader version:
2025-01-22 22:33:30 INFO Loading configuration from:
/usr/local/bin/sync-icloud.sh: source: line 13: can't open '': No such file or directory
2025-01-22 22:33:43 INFO ***** boredazfcuk/icloudpd container v1.0.1173_20-01-2025 started *****
2025-01-22 22:33:43 INFO ***** For support, please go here: https://github.com/boredazfcuk/docker-icloudpd *****
2025-01-22 22:33:43 INFO Alpine Linux 3.21.2
cat: /tmp/icloudpd/python_version: No such file or directory
2025-01-22 22:33:43 INFO Python version:
cat: /tmp/icloudpd/icloudpd_version: No such file or directory
2025-01-22 22:33:43 INFO icloud-photos-downloader version:
2025-01-22 22:33:43 INFO Loading configuration from:
/usr/local/bin/sync-icloud.sh: source: line 13: can't open '': No such file or directory
The text was updated successfully, but these errors were encountered: