[Bug]: Unable to mount TM folder when backing up

[timfrede]

Describe the Bug

I initially set up my Synology following a guide similar to this. I have a TimeMachine user that's in the Users group and a Time Machine shared folder with a 3 TB quota. The TimeMachine user was set to read/write on the shared folder, and all other users did not.

1. Since installing this docker image, the TimeMachine user is set to read only for the shared folder. Is this expected? It still backed up so it's working, but I was just curious if that mattered.
2. When TimeMachine is backing up, I am unable to access the Synology using my admin account to mount other folders in the Finder. I can still access other services webpages, Plex still works, etc. Once the backup is complete, I can log into the other folders in the Finder with no issues. Should I change the user that the docker container uses?

Expected Behavior

1. I would expect the user permissions to be set correctly (and they may be, but not sure).

2. I would expect to be able to access my other shared folders in the Finder while Time Machine is backing up.

Steps to Reproduce

1. Start Time Machine backup.
2. Cmd-K in Finder
3. Enter smb://192.168.1.200
4. This time it did connect but it appeared to kill the time machine connection as the backup stopped copying.

How You're Launching the Container

version: "3.7"
services:
  timemachine:
    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=users
      - TM_UID=1000
      - TM_GID=1000
      - PASSWORD=[PW]
      - SET_PERMISSIONS=false
      - SHARE_NAME=TimeMachine
      - SMB_INHERIT_PERMISSIONS=no
      - SMB_NFS_ACES=yes
      - SMB_METADATA=stream
      - SMB_PORT=445
      - SMB_VFS_OBJECTS=acl_xattr fruit streams_xattr
      - VOLUME_SIZE_LIMIT=0
      - WORKGROUP=WORKGROUP
    restart: unless-stopped
    volumes:
      - /volume1/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
    image: mbentley/timemachine:smb
    hostname: timemachine
    mac_address: "AA:BB:CC:DD:EE:FF"
    networks:
      timemachine:
        ipv4_address: 192.168.1.203
    labels:
      - "diun.enable=true"
      - "diun.watch_repo=true"
      - "diun.include_tags=latest" 

networks:
  timemachine:
    driver: macvlan
    driver_opts:
      parent: eth0
    ipam:
      config:
        - subnet: 192.168.1.0/24
          ip_range: 192.168.1.0/24
          gateway: 192.168.1.1

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

Container Logs

Uploaded logs below.

Additional Context

In the docker-compose file, I removed the ports on the first run because it didn't like that with the network_mode: "host". Then when I had to set up the macvlan, I had to remove the network_mode: "host". Username/PW are the TimeMachine user, shared folder is the TimeMachine folder I had from before. timemachine_logs.txt

[mbentley]

Do you know what the UID/GID of the user that you created on your Synology NAS are set to? I am guessing that the UID/GID of the user isn't 1000:1000 like how it is in the Time Machine container. The thing that really matters is the UID/GID of the user, not the username. If you really want, what you can do is get the UID/GID of the user on your Synology and update the compose file:

      - TM_UID=1000
      - TM_GID=1000

I am not sure how you'd find out what they are on a Synology from a web interface but from a terminal/ssh connection, it would be something like id timemachine.

[timfrede]

Good catch, I didn't see that. I found the UID/GID using the CLI command like you said, id timemachine. It returns uid=1029(timemachine) gid=100(users) groups=100(users),65538(timemachine). I updated the docker-compose file to match. However, I can no longer log in with the timemachine user. It is also setting the folder permissions back to read only. I noticed in the logs that it's not seeing the user and creating it. But it is finding the users group. timemachine_logs.txt

[mbentley]

With - SET_PERMISSIONS=false set, you'll need to make sure to manage the permissions accordingly for the persistent data directory on your host to match your expected users to their proper user:group (or uid:gid). I'm guessing that would be why you can't log in with the timemachine user.

[timfrede]

Is the uid hard coded somewhere? I noticed this error in the logs: add_local_groups: SID S-1-5-21-34802994-1959229442-1914783761-1000 -> getpwuid(1000) failed, is nsswitch configured? I deleted the timemachine user and group from the Synology, set the config file back to 1000:1000, set permissions=true and recreated the docker container. It created a user and group, and is currently backing up. (User and group are not visible in the normal user area though.) It does fail when our MacBook Air tried to back up at the same time, said the drive was busy. Should I make a new shared folder for the laptop?

[mbentley]

The only place that UID 1000 is set is when it's set as the default PUID which is the same as TM_UID and setting a TM_UID overrides the PUID value. I believe it would only complain about that when there would be an ownership/ACL issue potentially from what I found on some quick searching.

The issue of trying to back up multiple at the same time is odd. I don't have any issues backing up two Macs - I have an old MacBook Air on Big Sur and my m1 MacBook Air on Ventura where both are using the same user. Are you mounting the share first and then doing a backup or just trying to backup directly with the time machine utility without mounting (I do the latter with no manual mounting).

[timfrede]

I ended up blowing away the container and the extra drives it creates. I had bumped up the logging level to 3 and was getting Unix PW errors. It was strange because TM would find the backup, let me connect, but would never be able to mount the drive. Once I started over from scratch, I could see in the logs that it grabbed the correct UID:GID. I'm wondering if my first run loaded it with the default values, and it never updated it? It would also throw strange password errors even though the passwords were correct. Could it be something in the Samba config that was not getting updated?

Regardless, it's been working great now. Both computers have been backup up all weekend, and I can log into the Synology from the Finder while a backup is occurring.