-
Describe the BugI use the mbentley/timemachine:smb to run the time machine backup for MacOS Sonoma on Mac mini 20H1, but it failed with cannot create backup image with "Time Machine error: backup disk image could not be created". Expected BehaviorSuccessfully backup the Sonoma Steps to Reproduce
How You're Launching the ContainerContainer LogsTime Machine client LogsNo response Additional ContextNo response |
Beta Was this translation helpful? Give feedback.
Replies: 18 comments
-
|
Could you also provide the startup logs from the entrypoint? They provide additional info for me. |
Beta Was this translation helpful? Give feedback.
-
|
The startup log is pretty long, so i attached with a file. |
Beta Was this translation helpful? Give feedback.
-
|
The version of MacOS is 14.1, and docker version as following: Server: |
Beta Was this translation helpful? Give feedback.
-
|
OK, thanks. Looks like it's formatting the filesystem xfs just fine and it is passing the attribute check fine. What about the time machine client logs when you try to run a backup? You can try to trigger a backup and change That's a pretty ancient version of Docker there but I would be surprised if that was causing a problem. You have |
Beta Was this translation helpful? Give feedback.
-
|
Here is the client log of it. it seems the reason of permission, i'll try set_permissions=true and report the result. |
Beta Was this translation helpful? Give feedback.
-
|
There is no luck for -e SET_PERMISSIONS="true", it give me the same error and same log info for: Code=13 "Permission denied". The kernel of the host is 4.19.90 |
Beta Was this translation helpful? Give feedback.
-
|
You you re-post the container startup logs? Just the part down to where it says entrypoint complete is good enough, like this: Just want to make sure that it isn't having issues setting any permissions. Also, what's the host os? a |
Beta Was this translation helpful? Give feedback.
-
|
Docker log is here: |
Beta Was this translation helpful? Give feedback.
-
|
I was puzzled for these log information: I'm using smb, but why AFP_AfpInfo displayed in the log? |
Beta Was this translation helpful? Give feedback.
-
|
With time machine backup logs, I often seen quite a few messages that initially look like errors but they're more informative. As far as I know, time machine backups still support AFP so it may just be checking a sparsebundle for afp support. |
Beta Was this translation helpful? Give feedback.
-
|
So trimming down the client logs, it really comes down to this: To remove the possibility of the volume driver being an issue, do you have a location where you could bind mount with an existing filesystem to just test the ability to back up without it? |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunetly, it is not the cause of volume driver. The erros still exists. client.log is: Seem nothing has changed. |
Beta Was this translation helpful? Give feedback.
-
|
Hmm, try setting the env var for |
Beta Was this translation helpful? Give feedback.
-
|
It is the same result. container log: |
Beta Was this translation helpful? Give feedback.
-
|
Is the problem caused by kernel or docker version which are not compatibable with smb or netatalk？ |
Beta Was this translation helpful? Give feedback.
-
|
So, I am trying to see if I can find anything that sticks out error wise and I came across this: https://discuss.linuxcontainers.org/t/setting-extended-attributes-failed-reason-operation-not-permitted/10670/3 So it may be that there is an issue with the allowed syscalls that may be blocking things. A quick and dirty test would be to add the I have no idea if looking at the Docker daemon logs or the system logs (like syslog or whatever logging mechanism your OS uses) would show a blocking of some sort of syscall. |
Beta Was this translation helpful? Give feedback.
-
|
A good news is that, using |
Beta Was this translation helpful? Give feedback.
-
|
I would say that it is probably just better to just close the issue. If you want to troubleshoot further, you can try a few things:
If setting seccomp to unconfined works, you can see if there is a newer package for seccomp available for your distribution. But if you are find running the container as |
Beta Was this translation helpful? Give feedback.
So, I am trying to see if I can find anything that sticks out error wise and I came across this: https://discuss.linuxcontainers.org/t/setting-extended-attributes-failed-reason-operation-not-permitted/10670/3
So it may be that there is an issue with the allowed syscalls that may be blocking things. A quick and dirty test would be to add the
--privilegedflag to allow the container to bypass any potential restrictions. This might be something that would have been addressed with a newer version of Docker if it does work with--privileged. I suppose it could also be an out of date version of seccomp which would also be bypassed when using--privileged.I have no idea if looking at the Docker…