[Bug]: Authentication failed (macOS Ventura)

[SpeedmaxX]

Describe the Bug

Using this configuration

timemachine:
    image: mbentley/timemachine:latest
    container_name: timemachine
    restart: unless-stopped
    hostname: timemachine
    environment:
      - TM_UID=1000
      - TM_GID=1000
      - TM_USERNAME=timemachine
      - PASSWORD=timemachine
      - SET_PERMISSIONS=false
      - VOLUME_SIZE_LIMIT="1 T"
    volumes:
      - /home/markus/docker/timemachine:/opt/timemachine
    network_mode: "host"

I am trying to log in from the settings menu with user:timemachine and password:timemachine, but the authentication is always rejected.

When using a different username, login is successful, but wrong space is shown, only 6GB.

Expected Behavior

Login successful and correct space is shown

Steps to Reproduce

1. start settings in macOS Ventura (13.0.1)
2. go to timemachine-menu
3. chose docker-container as target
4. enter credentials

How You're Launching the Container

docker-compose -f docker-compose-t2.yml up -d

Container Logs

timemachine          | 2022-11-21T05:59:21.315863227Z query_name_response: Multiple (2) responses received for a query on subnet 192.168.123.77 for name WORKGROUP<1d>.
timemachine          | 2022-11-21T05:59:21.315960698Z This response was from IP 192.168.123.46, reporting an IP address of 192.168.123.46.
timemachine          | 2022-11-21T06:01:07.937391003Z Interface veth34e874b.IPv6 no longer relevant for mDNS.
timemachine          | 2022-11-21T06:01:07.937431595Z Leaving mDNS multicast group on interface veth34e874b.IPv6 with address fe80::2880:71ff:feb2:45ee.
timemachine          | 2022-11-21T06:01:07.958080788Z Withdrawing address record for fe80::2880:71ff:feb2:45ee on veth34e874b.
timemachine          | 2022-11-21T06:01:11.806250034Z Joining mDNS multicast group on interface veth9e0b426.IPv6 with address fe80::839:7aff:fee6:5f58.
timemachine          | 2022-11-21T06:01:11.806340772Z New relevant interface veth9e0b426.IPv6 for mDNS.
timemachine          | 2022-11-21T06:01:11.806372392Z Registering new address record for fe80::839:7aff:fee6:5f58 on veth9e0b426.*.
timemachine          | 2022-11-21T06:04:21.479969073Z query_name_response: Multiple (2) responses received for a query on subnet 192.168.123.77 for name WORKGROUP<1d>.
timemachine          | 2022-11-21T06:04:21.480064612Z This response was from IP 192.168.123.46, reporting an IP address of 192.168.123.46.
timemachine          | 2022-11-21T06:09:21.191591088Z query_name_response: Multiple (2) responses received for a query on subnet 192.168.123.77 for name WORKGROUP<1d>.
timemachine          | 2022-11-21T06:09:21.191689973Z This response was from IP 192.168.123.46, reporting an IP address of 192.168.123.46.

Additional Context

No response

[mbentley]

I just setup a new macOS VM to test a new setup on as I actually had not set up Time Machine from scratch since Monterey. It worked fine for me in terms of being able to use timemachine:timemachine for the username & password and it also worked fine for a custom password.

The space shown typically should be the actual free space available so it might either be that the disk/partition that is available at /home/markus/docker/timemachine isn't very large OR the reporting isn't working correctly. When I setup Time Machine in a VM to a new time machine container, it reported 1.1 TB available even though the partition that I used was only 30 GB with 15 GB free so there may be some issues reporting disk space, depending on the file system. In my case, it was xfs on my test where my regular setup uses zfs for the backing file system and it seems to report disk space accurately for me.

When I set up my test Time Machine in my VM, I connected manually to the share using Finder by entering the network path smb://<ip address> as it wasn't populating a list of available locations. Are you sure that the network share that was listed was definitely your time machine container? Are you running any other Samba based containers that may be showing up as the container listed, as you mentioned something that said docker-container as the target.

[jracoma]

Similar setup to above and able to set up time machine but fails to back up.

[mbentley]

Time Machine is difficult to debug. It might be worth trying out Time Machine Mechanic to see if it can identify why the backup isn't working automatically. The zip link comes from https://eclecticlight.co/consolation-t2m2-and-log-utilities/ but that website is a bit wall of text.