Timemachine Application Support Thread


Recommended Posts

Thank you @moritzf for bringing this to Unraid! I've got it configured and working perfectly for a single user setup. 

 

My one question is: when you're in the share settings should you leave the Included and Excluded disks as default (i.e. using all of them), or to force the share to just use one disk? I have read that in other Unraid Time Machine backup solutions it's best to keep the backup on a single disk. Is this the case for this docker?

 

This is how I have mine setup, and all is working well.

1093456003_Screenshot2022-08-19110418.thumb.png.1c8dd1fead720567a9941deb31493b30.png

 

So, my question is, is it better that have the share set to one disk, or just to leave everything there as default and allow it to use all disks? I have checked through this thread and the original docker and github documentation but could not find any mention of this, so I thought I would ask here. 

 

Thanks in advance!

Link to comment

I am not able to get this thing running 😞
When I select the timemachine-volume "Urzeitkapsel" and enter the credentials (defaults) my Mac says : "Das ausgewählte Backup-Volume im Netzwerk unterstützt die notwendigen Funktionen nicht." (The selected backup volume on the network does not support the necessary functions.).
In the docker-log is this output:

 

chpasswd: password for 'timemachine' changed
dbus-daemon[42]: [system] org.freedesktop.DBus.Error.AccessDenied: Failed to set fd limit to 65536: Operation not permitted
Found user 'avahi' (UID 86) and group 'avahi' (GID 86).
Successfully dropped root privileges.
avahi-daemon 0.8 starting up.
WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Loading service file /etc/avahi/services/smbd.service.
Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.2.250.
New relevant interface eth0.IPv4 for mDNS.
Joining mDNS multicast group on interface lo.IPv4 with address 127.0.0.1.
New relevant interface lo.IPv4 for mDNS.
Network interface enumeration completed.
Registering new address record for 192.168.2.250 on eth0.IPv4.
Registering new address record for 127.0.0.1 on lo.IPv4.
Server startup complete. Host name is timemachine.local. Local service cookie is 641408420.
Service "urzeitkapsel" (/etc/avahi/services/smbd.service) successfully established.
INFO: CUSTOM_SMB_CONF=false; generating [global] section of /etc/samba/smb.conf...
INFO: Creating /var/log/samba/cores
INFO: Avahi - generating base configuration in /etc/avahi/services/smbd.service...
INFO: Avahi - using urzeitkapsel as hostname.
INFO: Avahi - adding the 'dk0', 'Urzeitkapsel' share txt-record to /etc/avahi/services/smbd.service...
INFO: Group timemachine doesn't exist; creating...
INFO: User timemachine doesn't exist; creating...
INFO: Setting password from environment variable
INFO: INFO: CUSTOM_SMB_CONF=false; generating [Urzeitkapsel] section of /etc/samba/smb.conf...
INFO: Samba - Created Added user timemachine.
INFO: Samba - Enabled user timemachine.
INFO: Samba - setting password
INFO: changed ownership of '/opt/timemachine' to 1000:1000
INFO: mode of '/opt/timemachine' changed to 0770 (rwxrwx---)
INFO: Avahi - completing the configuration in /etc/avahi/services/smbd.service...
INFO: running test for xattr support on your time machine persistent storage location...
INFO: xattr test successful - your persistent data store supports xattrs
INFO: entrypoint complete; executing 's6-svscan /etc/s6'
dbus socket not yet available; sleeping...
nmbd version 4.15.7 started.
Copyright Andrew Tridgell and the Samba Team 1992-2021
smbd version 4.15.7 started.
Copyright Andrew Tridgell and the Samba Team 1992-2021
INFO: Profiling support unavailable in this build.
Failed to fetch record!
*****

Samba name server TIMEMACHINE is now a local master browser for workgroup VU on subnet 192.168.2.250

*****
error in mds_init_ctx for: /opt/timemachine
_mdssvc_open: Couldn't create policy handle for Urzeitkapsel

 

Any Ideas?

  • Like 1
Link to comment

So, as it seems no-one had converted this container to use AFP yet (or they're just keeping quiet about it 😉) here's how I did it after many attempts and equally many failures to get Time Machine working over SMB. There were a couple of non-obvious points (at least to a Docker and Unraid newbie like me). Many thanks are of course due to mbentley for the original container and moritzf for bringing it to Unraid; any problems you encounter with these instructions are undoubtedly down to errors or omissions on my part.

  1. Carefully read, understand, and accept the caveats that apply to the AFP tag in the "Image Tags" section of the Docker Hub page. In short: AFP is deprecated by Apple; the AFP tag is infrequently updated, less stable, will not receive new features, and may contain unpatched security vulnerabilities.
  2. Go and give the SMB version one last go. It's much better. Only use AFP if you've no other option.
  3. Edit the Time Machine Docker container.
  4. Switch to "advanced view" in the top right. We'll need some of those options
  5. Change the value in the "Repository" field to "mbentley/timemachine:afp"
  6. In the "Extra Parameters" field add " --ulimit nofile=65536:65536" after the --hostname parameter that should already be there. This will allow Docker (and hence Netatalk) to request more file descriptors than it has by default.
  7. Keep the custom network; it'll allow the service to be advertised by Avahi.
  8. Remove the following unnecessary parameters: "Size Limit", "Advertised Hostname", "Use Custom SMB Configuration", "Debug Level", "External Configuration Directory", "Hide Shares", "SMB Inherit Permissions", "SMB fruit:nfs_aces", "SMB fruit:metadata", "SMB Port", "SMB vfs objects", and "SMB Workgroup Name". (You don't strictly need to do this, but it will keep things tidy and prevent confusion later on.)
  9. The remaining ten parameters have the same semantics as they do in the SMB version. Set them or leave the default values as you see fit.
  10. Add the following Variables: CUSTOM_AFP_CONF, CUSTOM_USER, LOG_LEVEL, and VOLUME_SIZE_LIMIT. Descriptions and default values can be seen by expanding the "AFP Examples and Variables" section at the bottom of the Docker Hub page. All but VOLUME_SIZE_LIMIT can be left to default. N.B.: VOLUME_SIZE_LIMIT is different from the identically-named SMB incarnation. You cannot specify a unit; only the number of mebibytes (MiB) you want to set as a limit.
  11. The Docker should run and you should be able to select it in Time Machine preferences.

The oddities I have found:

  • To see what Netatalk's up to in detail, you have to open a console and tail or otherwise look in /var/log/supervisor/netatalk.log . I'm not experienced enough with Docker to say whether these messages being excluded from the easily-available logs is a feature, bug, or (most likely) a misconfiguration on my part.
  • I seem to get "afpd[1511] {quota.c:646} (info:AFPDaemon): getquota: special /opt/[$TM_USERNAME] fails" entries in the Netatalk log at least once per backup. I don't know exactly what it means, but it doesn't seem to cause any problems.
  • I don't know what the "right" number of file descriptors to assign to Netatalk is, how to find it out, or what the negative consequences (if any) of over-provision are. 65536 was the first suggestion I saw when Googling file descriptors in Unraid Docker, and seemed to work.
  • Sometimes it just gets its knickers in a twist when it starts up and backups will fail with a message along the lines of "the selected device does not support the necessary operations". Simply restarting the container will usually cure it, although occasionally I've got it so fankled up it just won't exit. The only solution I've found is to SSH into the host and do a docker kill --signal=9 on it. I haven't been able to pin these cases down to a cause yet, but it seems to be a startup thing: once the first backup begins you can be reasonably confident in it lasting for a few days at least.
Edited by ScottAS2
Link to comment
  • 3 weeks later...
On 8/5/2022 at 5:36 PM, 54lzy said:

I tried to set this up after reading that it works (and 6.10 does not). I get the following errors:

 

Failed to fetch record!
error in mds_init_ctx for: /opt/timemachine
_mdssvc_open: Couldn't create policy handle for TimeMachine
error in mds_init_ctx for: /opt/timemachine
_mdssvc_open: Couldn't create policy handle for TimeMachine
talloc: access after free error - first free may be at ../../tevent_req.c:291
Bad talloc magic value - access after free
===============================================================
INTERNAL ERROR: Bad talloc magic value - access after free in pid 48 (4.15.7)
If you are running a recent Samba version, and if you think this problem is not yet fixed in the latest versions, please consider reporting this bug, see https://wiki.samba.org/index.php/Bug_Reporting
===============================================================
PANIC (pid 48): Bad talloc magic value - access after free in 4.15.7
unable to produce a stack trace on this platform
dumping core in /var/log/samba/cores/smbd

 

Does anyone have any advise as to how to resolve?

 

I have the same problem. I can mount the drive but as soon as I click backup it does the same

Link to comment

Hey, thanks for getting this docker out there. I tried to use the builtin support (and YouTube video) without success.  For those of you struggling.... I am only using one user for now, just to get it working... I installed it, didn't change any settings, and ran the command line to fix permissions.  ON the mac, I didn't map any drives or connect to it in Finder. I just went into TimeMachine, it saw the advertised disk, clicked on that and away it went backing up. Super easy!! 

Link to comment
  • 1 month later...
On 6/4/2022 at 2:11 AM, wgstarks said:

It took me several days of trial and error to get this docker working for multiple macs so I decided to writeup the process and perhaps save someone else some headaches. In my case I followed the multiple user guide in the mbentley/docker-timemachine GitHub repo.

 

DISCLAIMER: I'm not an expert on Time Machine or dockers and hopefully I haven't included any errors in this guide but there may be some. If you find any please let me know.

 

Docker configuration screeshots-

1377775778_ScreenShot2022-06-03at7_17_04PM.thumb.png.d49f1ceaae35d5ae8b3f58c1c42cddde.png

944124111_ScreenShot2022-06-03at7_18_30PM.thumb.png.c37885d5b0b18b546ce0cd00be341260.png

1354229027_ScreenShot2022-06-03at7_18_47PM.thumb.png.9a272695928f3d9c9a58da6df7e784e9.png

Most of these settings are left as default.

 

Changes/additions needed:

 

1. You will need to create configuration files (example below) for each user you are adding. For EXTERNAL CONFIGURATION DIRECTORY variable add a path that is within the container for those files. I used /users since that's the path used in the GitHub example. You will also need to add a new path in the docker configuration to map the container path to the actual host path. Since I used my appdata folder for this the new path was /mnt/users/appdata/timemachine/:/users.

 

1970305047_ScreenShot2022-06-03at7_36_51PM.thumb.png.0181dd1fb145a897b89ddace6cb372ea.png

 

 

2. Each user must have a path set for the backup data mapped to /opt/<username> in the container. One path is already configured in the template. Additional paths must be added as needed. I let the docker create these shares (rather than me creating them ahead of time) so that they are configured properly.

 

1247015737_ScreenShot2022-06-03at7_43_04PM.thumb.png.ad68c0d1dd350fa4fd5d0f03f6e53d3c.png

 

 

3. Create the user configuration files mentioned above. These files must be named <username>.conf and each must have a unique TM_UID number.

 

m1_mini.conf

TM_USERNAME=m1_mini
TM_GROUPNAME=timemachine
PASSWORD=****************
SHARE_NAME=m1_miniSMB
VOLUME_SIZE_LIMIT=”1 T”
TM_UID=1001
TM_GID=1000

 

jasper.conf

TM_USERNAME=jasper
TM_GROUPNAME=timemachine
PASSWORD=******************
SHARE_NAME=jasperSMB
VOLUME_SIZE_LIMIT=”1 T”
TM_UID=1002
TM_GID=1000

 

Note the unique TM_UID numbers.

 

 

4. After starting the docker and allowing it to create the shares configured open a terminal window and run this command adjusted to match the names of your shares and the proper UID and GID numbers.

sudo chown -R <UID>:<GID> /mnt/user/<nameofshare>/

You will need to run this command for each user/share configured in the docker.

 

 

After completing these steps start a TimeMachine backup and check the destination share to be sure TM is writing to a sparsebundle file in that share. I had multiple failures when trying to get this docker working because I had mapped paths incorrectly in the host paths as well as the container paths. This will cause the backup to write to your docker image and rapidly fill it, so catch it before it becomes a problem.

 

Thank you for the quick guide. Was able to get my timemachine up and running again with two macBook using this guide, and everything works smooth again. 

Link to comment

Hey, just throwing my hat in the ring to say that I also am getting the errors:

 

Failed to fetch record!
*****

Samba name server TIMEMACHINE is now a local master browser for workgroup WORKGROUP on subnet 192.168.1.2

*****
error in mds_init_ctx for: /opt/timemachine
_mdssvc_open: Couldn't create policy handle for TimeMachine
error in mds_init_ctx for: /opt/timemachine
_mdssvc_open: Couldn't create policy handle for TimeMachine
error in mds_init_ctx for: /opt/timemachine
_mdssvc_open: Couldn't create policy handle for TimeMachine
error in mds_init_ctx for: /opt/timemachine
_mdssvc_open: Couldn't create policy handle for TimeMachine
error in mds_init_ctx for: /opt/timemachine
_mdssvc_open: Couldn't create policy handle for TimeMachine
error in mds_init_ctx for: /opt/timemachine
_mdssvc_open: Couldn't create policy handle for TimeMachine
error in mds_init_ctx for: /opt/timemachine
_mdssvc_open: Couldn't create policy handle for TimeMachine

 

I managed to get a full backup and it seems to be working just fine. Might just be a bug or something, I'm not too concerned.

 

---

 

GENERAL HELP FOR OTHERS

Make sure your share name is the same name as the docker compose's "User Name". My share was called "time machine" but my username was the default "timemachine" which filled up my docker.img.

 

It's often recommend to keep time machine backups to a single disk. I'm not sure if it applies here, but it doesn't hurt.

 

The usual recommendation for "what size should my time machine backup be?" is 2 x your Mac's disk size. I have a 1TB disk, so I made it 2TB.

 

Hope that helps!

Link to comment

So I got the TM running and the Backup also starts on my Macbook. So this is progress :)

 

However, I noticed that my Docker Image fills up once started. In order to fix it I had to Restart and than turn the docker off. somehow it recovered than. before I want to give it another shot I thought to maybe ask here if someone encountered the same issue or has an idea how i can fix that.

Link to comment
38 minutes ago, Aluavin said:

So I got the TM running and the Backup also starts on my Macbook. So this is progress :)

 

However, I noticed that my Docker Image fills up once started. In order to fix it I had to Restart and than turn the docker off. somehow it recovered than. before I want to give it another shot I thought to maybe ask here if someone encountered the same issue or has an idea how i can fix that.

This usually means that you don’t have paths set correctly. For me it was because I changed the user name but didn’t change the container path to match. It must be /opt/<new user name>. If that doesn’t help post your docker run command. Be sure to redact passwords if there are any,

Link to comment

Thank you for your reply, I checked and as far as I understand my config should do the trick, however the Docker Image keeps filling. My current config looks something like this:
 

docker run
  -d
  --name='TimeMachine'
  --net='br0'
  --ip='192.168.178.9'
  -e TZ="Europe/Berlin"
  -e HOST_OS="Unraid"
  -e HOST_HOSTNAME="Aluavin"
  -e HOST_CONTAINERNAME="TimeMachine"
  -e 'VOLUME_SIZE_LIMIT'='1 T'
  -e 'TM_USERNAME'='Aluavin'
  -e 'PASSWORD'='<removed>'
  -e 'ADVERTISED_HOSTNAME'='timemachine'
  -e 'CUSTOM_SMB_CONF'='false'
  -e 'CUSTOM_USER'='false'
  -e 'DEBUG_LEVEL'='1'
  -e 'MIMIC_MODEL'='TimeCapsule8,119'
  -e 'EXTERNAL_CONF'=''
  -e 'HIDE_SHARES'='no'
  -e 'TM_GROUPNAME'='timemachine'
  -e 'TM_UID'='1000'
  -e 'SET_PERMISSIONS'='false'
  -e 'SMB_INHERIT_PERMISSIONS'='no'
  -e 'SMB_NFS_ACES'='yes'
  -e 'SMB_METADATA'='stream'
  -e 'SMB_PORT'='445'
  -e 'SMB_VFS_OBJECTS'='acl_xattr fruit streams_xattr'
  -e 'WORKGROUP'='WORKGROUP'
  -e 'TM_GID'='1000'
  -e 'SHARE_NAME'='TimeMachine'
  -l net.unraid.docker.managed=dockerman
  -l net.unraid.docker.icon='https://upload.wikimedia.org/wikipedia/de/f/f4/Time_Machine_%28Apple%29_Logo.png'
  -v '/mnt/user/timemachine/fewald':'/opt/timemachine':'rw'
  --hostname timemachine 'mbentley/timemachine'

ba827ece46dd7bde741e3240fa345c1e8564b463a1732b54be840f20b1f482c5


 

Link to comment

It’s been a while since I setup mine but it looks like you have TM username set to Aluavin. The container path must match the TM username so it should be /mnt/user/timemachine/fewald:/opt/Aluavin or you could change the TM username back to the default. The reason your docker image is filing is because the docker is writing the backups to /opt/Aluavin but you don’t have a physical path defined for that so it’s in memory.

Link to comment
1 hour ago, wgstarks said:

It’s been a while since I setup mine but it looks like you have TM username set to Aluavin. The container path must match the TM username so it should be /mnt/user/timemachine/fewald:/opt/Aluavin or you could change the TM username back to the default. The reason your docker image is filing is because the docker is writing the backups to /opt/Aluavin but you don’t have a physical path defined for that so it’s in memory.



This did the trick. so the template itself has to be modified. Thank you very much!

Link to comment
  • 2 weeks later...

Hoping someone might be able to help a n00b with just enough knowledge to hurt himself...

 

I have 2 Macs using this plug in:

 

Both share the same TM login/instance of the docker.

Mac1 (Ventura), TM completes the initial backup to unRAID just fine as well as perform hourly backups

Mac2 (Big Sur), TM completes the initial backup to unRAID, but will not make subsequent backups. Note: it also successfully backs up to a local TM external drive.

 

Not sure what the command is to list the docker run info, but here is the log file:

 

text  error  warn  system  array  login  

Successfully dropped root privileges.
avahi-daemon 0.8 starting up.
WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
dbus_bus_get_private(): Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused
WARNING: Failed to contact D-Bus daemon.
avahi-daemon 0.8 exiting.
dbus-daemon[31]: [system] org.freedesktop.DBus.Error.AccessDenied: Failed to set fd limit to 65536: Operation not permitted
Found user 'avahi' (UID 86) and group 'avahi' (GID 86).
Successfully dropped root privileges.
avahi-daemon 0.8 starting up.
WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Loading service file /etc/avahi/services/smbd.service.
Joining mDNS multicast group on interface eth0.IPv4 with address x.x.x.2.
New relevant interface eth0.IPv4 for mDNS.
Joining mDNS multicast group on interface lo.IPv4 with address 127.0.0.1.
New relevant interface lo.IPv4 for mDNS.
Network interface enumeration completed.
Registering new address record for x.x.x.2 on eth0.IPv4.
Registering new address record for 127.0.0.1 on lo.IPv4.
Server startup complete. Host name is timemachine.local. Local service cookie is 251226102.
Service "timemachine" (/etc/avahi/services/smbd.service) successfully established.
Got SIGTERM, quitting.
Leaving mDNS multicast group on interface eth0.IPv4 with address x.x.x.2.
Leaving mDNS multicast group on interface lo.IPv4 with address 127.0.0.1.
avahi-daemon 0.8 exiting.
Found user 'avahi' (UID 86) and group 'avahi' (GID 86).
Successfully dropped root privileges.
avahi-daemon 0.8 starting up.
WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
dbus_bus_get_private(): Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused
WARNING: Failed to contact D-Bus daemon.
avahi-daemon 0.8 exiting.
dbus-daemon[31]: [system] org.freedesktop.DBus.Error.AccessDenied: Failed to set fd limit to 65536: Operation not permitted
Found user 'avahi' (UID 86) and group 'avahi' (GID 86).
Successfully dropped root privileges.
avahi-daemon 0.8 starting up.
WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Loading service file /etc/avahi/services/smbd.service.
Joining mDNS multicast group on interface eth0.IPv4 with address x.x.x.2.
New relevant interface eth0.IPv4 for mDNS.
Joining mDNS multicast group on interface lo.IPv4 with address 127.0.0.1.
New relevant interface lo.IPv4 for mDNS.
Network interface enumeration completed.
Registering new address record for x.x.x.2 on eth0.IPv4.
Registering new address record for 127.0.0.1 on lo.IPv4.
Server startup complete. Host name is timemachine.local. Local service cookie is 2018396226.
Service "timemachine" (/etc/avahi/services/smbd.service) successfully established.
nmbd version 4.15.7 started.
Copyright Andrew Tridgell and the Samba Team 1992-2021
query_name_response: Multiple (2) responses received for a query on subnet x.x.x.2 for name WORKGROUP<1d>.
This response was from IP x.x.x.100, reporting an IP address of x.x.x.100.
smbd version 4.15.7 started.
Copyright Andrew Tridgell and the Samba Team 1992-2021
INFO: Profiling support unavailable in this build.
Failed to fetch record!
query_name_response: Multiple (2) responses received for a query on subnet x.x.x.2 for name WORKGROUP<1d>.
This response was from IP x.x.x.100, reporting an IP address of x.x.x.100.
query_name_response: Multiple (2) responses received for a query on subnet x.x.x.2 for name WORKGROUP<1d>.
This response was from IP x.x.x.100, reporting an IP address of x.x.x.100.
query_name_response: Multiple (2) responses received for a query on subnet x.x.x.2 for name WORKGROUP<1d>.
This response was from IP x.x.x.100, reporting an IP address of x.x.x.100.
Got SIGTERM: going down...
Executing .s6-svscan/finish with arguments 
INFO: CUSTOM_SMB_CONF=false; generating [global] section of /etc/samba/smb.conf...
INFO: Avahi - generating base configuration in /etc/avahi/services/smbd.service...
INFO: Avahi - using timemachine as hostname.
INFO: Avahi - adding the 'dk0', 'TimeMachine' share txt-record to /etc/avahi/services/smbd.service...
INFO: Group timemachine exists; skipping creation
INFO: User timemachine exists; skipping creation
INFO: CUSTOM_SMB_CONF=false; generating [TimeMachine] section of /etc/samba/smb.conf...
INFO: Samba - Created User timemachine password set to none.
INFO: Samba - Enabled user timemachine.
INFO: Samba - setting password
INFO: SET_PERMISSIONS=false; not setting ownership and permissions for /opt/timemachine
INFO: Avahi - completing the configuration in /etc/avahi/services/smbd.service...
INFO: samba-bgqd PID exists; removing...
removed '/run/samba/samba-bgqd.pid'
INFO: dbus PID exists; removing...
removed '/run/dbus/dbus.pid'
INFO: running test for xattr support on your time machine persistent storage location...
INFO: xattr test successful - your persistent data store supports xattrs
INFO: entrypoint complete; executing 's6-svscan /etc/s6'
nmbd version 4.15.7 started.
Copyright Andrew Tridgell and the Samba Team 1992-2021
query_name_response: Multiple (2) responses received for a query on subnet x.x.x.2 for name WORKGROUP<1d>.
This response was from IP x.x.x.100, reporting an IP address of x.x.x.100.
smbd version 4.15.7 started.
Copyright Andrew Tridgell and the Samba Team 1992-2021
INFO: Profiling support unavailable in this build.
Failed to fetch record!

 

I'm out of ideas... thanks guys.

 

 

 

Link to comment
22 minutes ago, Joseph said:

I'm out of ideas... thanks guys.

This is really just a shot in the dark but the first thing I would try is deleting everything on the share you’re backing up to and then just connect the Big Sur machine (remove this location from the Ventura machine) and see if it works properly then. If so, you should probably setup separate shares for the two machines.

https://forums.unraid.net/topic/123985-timemachine-application-support-thread/?do=findComment&comment=1134386

 

FYI, if you click this (or any) docker run link it shows you how to get the data.

Link to comment
16 hours ago, wgstarks said:

If so, you should probably setup separate shares for the two machines.

ok, will try that, thank you!

 

Quote

FYI, if you click this (or any) docker run link it shows you how to get the data.

Doh! Thanks... here it is:

 

docker run
  -d
  --name='TimeMachine'
  --net='br0'
  -e TZ="Europe/Berlin"
  -e HOST_OS="Unraid"
  -e HOST_HOSTNAME="Backup"
  -e HOST_CONTAINERNAME="TimeMachine"
  -e 'VOLUME_SIZE_LIMIT'='6 T'
  -e 'TM_USERNAME'='timemachine'
  -e 'PASSWORD'='[REMOVED]'
  -e 'ADVERTISED_HOSTNAME'='timemachine'
  -e 'CUSTOM_SMB_CONF'='false'
  -e 'CUSTOM_USER'='false'
  -e 'DEBUG_LEVEL'='1'
  -e 'MIMIC_MODEL'='TimeCapsule8,119'
  -e 'EXTERNAL_CONF'=''
  -e 'HIDE_SHARES'='no'
  -e 'TM_GROUPNAME'='timemachine'
  -e 'TM_UID'='1000'
  -e 'SET_PERMISSIONS'='false'
  -e 'SMB_INHERIT_PERMISSIONS'='no'
  -e 'SMB_NFS_ACES'='yes'
  -e 'SMB_METADATA'='stream'
  -e 'SMB_PORT'='445'
  -e 'SMB_VFS_OBJECTS'='acl_xattr fruit streams_xattr'
  -e 'WORKGROUP'='WORKGROUP'
  -e 'TM_GID'='1000'
  -e 'SHARE_NAME'='TimeMachine'
  -l net.unraid.docker.managed=dockerman
  -l net.unraid.docker.icon='https://upload.wikimedia.org/wikipedia/de/f/f4/Time_Machine_%28Apple%29_Logo.png'
  -v '/mnt/user/timemachine/':'/opt/timemachine':'rw'
  --hostname timemachine 'mbentley/timemachine' 
6ca23edde97fa1d05724abb35e0e3af9dc0a12a885b53d04c817598540f342bf

 

 

UPDATE 1: Ok, so blew away the TM data/share and reinstalled the app to set up 2 shares per your detailed & amazing instructions. The first one (Big Sur) just started... will keep you posted. Thanks again!

Edited by Joseph
update
Link to comment
On 11/21/2022 at 5:58 PM, wgstarks said:

If so, you should probably setup separate shares for the two machines.

https://forums.unraid.net/topic/123985-timemachine-application-support-thread/?do=findComment&comment=1134386

 

So I followed the instructions to create 2 different users (and different share names). I changed the UID and GID for each share name and started a backup, but it didn't complete, and has stopped working altogether. Both shares before chown: UID=timemachine; GID=1000:

 

I think I did this correctly?:

* sudo chown -R TM_MP:1001/mnt/user/TM_MP_SMB/

* sudo chown -R TM_MBP:1002/mnt/user/TM_MBP_SMB/

 

When I check the results of each share I get:

* TM_MP_SMB UID !=timemachine or TM_MP; GID=1000

* TM_MBP_SMB UID !=timemachine or TM_MBP; GID=1000

 

So there's something wrong with the both share owners and the group is set to 1000.

 

Can you let me know they should be for each share and how the permissions should be set? My guess is owner should either be timemachine and group 1000 for both or it should be set to their respective UIDs & GIDs; but that's not what I have.

 

Thanks in advance!

Edited by Joseph
Link to comment
On 11/21/2022 at 5:58 PM, wgstarks said:

If so, you should probably setup separate shares for the two machines.

https://forums.unraid.net/topic/123985-timemachine-application-support-thread/?do=findComment&comment=1134386

 

UPDATE 1: so I changed the owner on both shares to nobody and group to 1000 set the perms to 777 and tried the Big Sur TM again. The first backup completed, however subsequent backups still fail... so SS/DD! :(

 

UPDATE 2: Using the same perms & owner as above, TM on the Mac running Ventura seems to be just fine... so both are behaving just as before; Ventura works, Big Sur does not. Unless I borked the setup/install of the docker (which is within the realm of possibilities), I'm leaning toward its a limitation with Big Sur itself or maybe has something to do with having a local backup on the Big Sur Mac as well.

Edited by Joseph
Link to comment
On 11/26/2022 at 10:32 AM, Joseph said:

UPDATE 2: Using the same perms & owner as above, TM on the Mac running Ventura seems to be just fine... so both are behaving just as before; Ventura works, Big Sur does not. Unless I borked the setup/install of the docker (which is within the realm of possibilities), I'm leaning toward its a limitation with Big Sur itself or maybe has something to do with having a local backup on the Big Sur Mac as well.

I had similar issues at one point and corrected them by re-installing macOS. This apparently doesn't work for everyone though. It's a simple process, roughly equivalent to installing an update, if you want to give it a try.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.