[Bug]: "Time Machine error: backup disk image could not be created"

[0xAdriaTorralba]

Describe the Bug

Setup new backup TM on MacOS Sonoma. Getting error "Time Machine error: backup disk image could not be created" on the Settings UI.

I am getting "set_canon_ace_list: sys_acl_set_file on file [66B5EF10-4F6D-5480-849B-8F65CA52AC71_2023-09-28-015725.sparsebundle/lock]: (Not supported)" on the docker logs regarding SMB.

chmod -R 777 and chown -R timemachine:timemachine on the destination of the backup.

In the Finder, I can see that this creates a file 66B5EF10-4F6D-5480-849B-8F65CA52AC71_2023-09-28-015009.sparsebundle and immediately after that it renames the file to 66B5EF10-4F6D-5480-849B-8F65CA52AC71_2023-09-28-015009.purgable.

Expected Behavior

Create the backup disk.

Steps to Reproduce

1. Add remote disk
2. Setup disk configuration
3. Backup is not working.

How You're Launching the Container

timemachine:
    image: dubodubonduponey/netatalk:v1
    build: docker-timemachine
    volumes:
      - 'resin-data:/downloads'
    privileged: true
    restart: unless-stopped
    environment:
      - USERS=timemachine
      - PASSWORDS=timemachine
      - NAME=rpi
      - AVAHI_NAME=rpi
    cap_add:
      - NET_BIND_SERVICE
      - CHOWN
      - FOWNER
      - SETUID
      - SETGID
      - DAC_OVERRIDE
    cap_drop:
      - ALL
    network_mode: host

Container Logs

timemachine  set_canon_ace_list: sys_acl_set_file on file [66B5EF10-4F6D-5480-849B-8F65CA52AC71_2023-09-28-015725.sparsebundle/mapped]: (Not supported)
 timemachine  parse_dfs_path_strict: Hostname f1e214f._smb._tcp.local is not ours.

Additional Context

No response

[mbentley]

Is the image name right? dubodubonduponey/netatalk:v1?

[0xAdriaTorralba]

Which image should it be?

[mbentley]

Well, mine is mbentley/timemachine which this repo is for. I know nothing about some other person's image so I won't be able to help with that. If you are intending to try to use mine, check out the extensive readme in the project root.

Assuming the image you are using really is using netatalk, Apple has deprecated netatalk for some time now.

[0xAdriaTorralba]

I see, I tried using your default configuration using your docker image and I get the same result. I can't figure what I should put on the "path to your timemachine drive" on the volumes.

    network_mode: "host"
    environment:
      - CUSTOM_SMB_CONF=false
      - CUSTOM_USER=false
      - DEBUG_LEVEL=1
      - EXTERNAL_CONF=
      - HIDE_SHARES=no
      - MIMIC_MODEL=TimeCapsule8,119
      - TM_USERNAME=timemachine
      - TM_GROUPNAME=timemachine
      - TM_UID=1000
      - TM_GID=1000
      - PASSWORD=timemachine
      - SET_PERMISSIONS=false
      - SHARE_NAME=TimeMachine
      - SMB_INHERIT_PERMISSIONS=no
      - SMB_NFS_ACES=no
      - SMB_METADATA=stream
      - SMB_PORT=445
      - SMB_VFS_OBJECTS=acl_xattr fruit streams_xattr
      - VOLUME_SIZE_LIMIT=0
      - WORKGROUP=WORKGROUP
    restart: unless-stopped
    ports:
      - "137:137/udp"
      - "138:138/udp"
      - "139:139"
    volumes:
      #- timemachine:/opt/timemachine
      - timemachine-var-lib-samba:/var/lib/samba
      - timemachine-var-cache-samba:/var/cache/samba
      - timemachine-run-samba:/run/samba
    ulimits:
      nofile:
        soft: 65536
        hard: 65536
    container_name: timemachine
    privileged: true
    image: mbentley/timemachine:smb

[mbentley]

That's up to you. Where do you want to store your time machine backups on your host?

[0xAdriaTorralba]

I mount my external HDD on /opt/timemachine already.

configuring someting like: - /opt/timemachine:/opt/timemachine is not allowed to do, I get "bind mount not allowed" error on BalenaCloud.

[mbentley]

Sounds like you’re running on a host that doesn’t allow bind mounts but that’s not a normal error; I’ve never hear of that exact error with docker. Are you trying to run time machine on a cloud instance and backup over the internet?

[0xAdriaTorralba]

I have a raspberry pi 4 with balenaOS, it is connected to BalenaCloud in order to handle the containers that I have on my raspi. One of these containers contain the image you provide on this Github repository. I have researched how to create "bind mounts" on balenaOS but I can't find anyting.

[0xAdriaTorralba]

Well, that is one of a kind type of bug I found...

My setup is raspi <-> ISP router <-> my Mac all through Ethernet cable.

Now, if I try to backup (from zero) while my Mac is connected through Ethernet, the backup image disk can't be created, but if I backup it through Wi-Fi, it does create the image disk...

Right now I am backing my entire laptop through Wi-Fi...

I'll check if, after the initial backup, I can backup the next incremental backups through Ethernet...

I'll keep you posted.

Thank you for all the help!

Btw, do you have any knowledge about this kind of issue...?

[mbentley]

That’s not something that I have come across. I also haven’t tried to backup over ethernet in a while but when I get a chance, I can setup a quick VM of Sonoma and try a new backup.

[dmitriykhait]

i ran into same issue after upgrading to sonoma, it was working fine before

[mbentley]

Well unfortunately, I spun up a new VM of Sonoma using tart and started up a brand new time machine on another linux box using the below compose file and it backed up successfully, with no issues.

version: "3.7"
services:
  timemachine:
    network_mode: "host"
    environment:
      - CUSTOM_SMB_CONF=false
      - CUSTOM_USER=false
      - DEBUG_LEVEL=1
      - EXTERNAL_CONF=
      - HIDE_SHARES=no
      - MIMIC_MODEL=TimeCapsule8,119
      - TM_USERNAME=timemachine
      - TM_GROUPNAME=timemachine
      - TM_UID=1000
      - TM_GID=1000
      - PASSWORD=timemachine
      - SET_PERMISSIONS=false
      - SHARE_NAME=TimeMachine
      - SMB_INHERIT_PERMISSIONS=no
      - SMB_NFS_ACES=no
      - SMB_METADATA=stream
      - SMB_PORT=445
      - SMB_VFS_OBJECTS=acl_xattr fruit streams_xattr
      - VOLUME_SIZE_LIMIT=0
      - WORKGROUP=WORKGROUP
    restart: unless-stopped
    ports:
      - "137:137/udp"
      - "138:138/udp"
      - "139:139"
    volumes:
      - timemachine-data:/opt/timemachine
      - timemachine-var-lib-samba:/var/lib/samba
      - timemachine-var-cache-samba:/var/cache/samba
      - timemachine-run-samba:/run/samba
    ulimits:
      nofile:
        soft: 65536
        hard: 65536
    container_name: timemachine
    image: mbentley/timemachine:smb

volumes:
  timemachine-data:
  timemachine-var-lib-samba:
  timemachine-var-cache-samba:
  timemachine-run-samba:

[mbentley]

If you're still having problems, give something like this a shot as the image was updated pretty significantly recently with some changes that seem to help with consistency:

version: "3.7"
services:
  timemachine:
    network_mode: "host"
    environment:
      - DEBUG_LEVEL=1
      - TM_USERNAME=timemachine
      - TM_GROUPNAME=timemachine
      - TM_UID=1000
      - TM_GID=1000
      - PASSWORD=timemachine
      - SET_PERMISSIONS=false
      - SHARE_NAME=TimeMachine
      - VOLUME_SIZE_LIMIT=0
      - WORKGROUP=WORKGROUP
    restart: unless-stopped
    volumes:
      - timemachine-data:/opt/timemachine
    tmpfs:
      - /run/samba
    ulimits:
      nofile:
        soft: 65536
        hard: 65536
    container_name: timemachine
    image: mbentley/timemachine:smb

volumes:
  timemachine-data:

[mbentley]

I am going to close this for now but let me know if there is new info to work from to help.