Confirm that `deploy` doesn't overwrite previous data/Time Machine backups

[jamesyc]

Confirm that deploy doesn't overwrite previous data/Time Machine backups

[jamesyc]

Current roadblock: need to wait for macOS 26.5 to fix Time Machine on the mac side.

Then do an uninstall on my Time Machine, make a few backups with the old Apple AFP path, drop a few files on the network share. Then try deploy and see if it still works.

[jamesyc]

It's stable enough to try and run this end-to-end check now, so here goes:

[jamesyc]

Then backing up again via Apple AFP:

[jamesyc]

AFP backup complete:

[jamesyc]

Deploy worked:

➜  TimeCapsuleSMB git:(netbsd4-refactor) ✗ .venv/bin/tcapsule deploy --install-nbns --debug-logging
Deploying...
Detected supported device: NetBSD 6.0 (evbarm, little-endian).
Using NetBSD 6 little-endian payload...
Deployed Samba payload to /Volumes/dk2/.samba4
Updated /mnt/Flash boot files.
This will reboot the Time Capsule now. Continue? [Y/n]: y
Reboot requested. Waiting for the device to go down...
Waiting for the device to come back up...
Device is back online.
Waiting for managed smbd to finish starting...
Waiting for managed mDNS takeover to finish...
Post-deploy verification:
  Advertised service name: Time Capsule Samba 4
  Advertised hostname: timecapsulesamba4.local:445
  Authenticated SMB listing: ok (admin@timecapsulesamba4.local)

[jamesyc]

Backup in progress:

[jamesyc]

It works!

Note that since we kill the AFP server, the top "AirPort Disk - James's AirPort Time Capsule.local" is expected to not be working.

[houmark]

Hey there @jamesyc. I've been looking around for this information prior to trying to install this on my A1470 Time Capsule.

And by the way, thanks a bunch for creating this. It's nice to see that people care to keep old hardware working. It's been a few years since I added a 12‑terabyte hard drive to my time capsule, so I was a bit sad to see that I would have to rip it out and figure something else out. But this should give me more time to think about a super long‑term solution, which probably involves a NAS.

Now back to my question.

I have maybe a two-year‑long running backup of my current Mac on the Time Capsule with AFP. My question is: what is my easiest path to re‑utilize my current sparse bundle and continue backing up without doing a complete fresh backup and losing my history data after having added the Samba software? And can I even reuse my sparse bundle?

Don't want to be annoying, and I would be happy to add this into the FAQ through a pull request after having successfully confirmed this path myself.

But it would be nice if you could quickly outline how this is done, unless it's fully automatic, of course (or through using Internal Share Uses Disk Root?). Even if that's the case, I think this is worthy of an entry in the FAQ or even in the installation instructions so people can see and have peace that their existing backups would continue to work.

[jamesyc]

@houmark it should work by default- if you follow the directions, it should allow you to reuse your backup.

I haven't tested it in several versions, though. So it might have some issues currently.

You can just try installing TimeCapsuleSMB, and see if time machine still recognizes the backup. If not, click on the uninstall section of the app and let me know. It doesnt touch your sparsebundle so it shouldnt damage your backup. I intentionally made it easy to fully uninstall. Let me know if you run into any issues.

The biggest issue is #177 which means your device may factory reset, but that just resets the settings, not the hard disk, so you won't have any data loss. Just annoying if you have to set up your settings again.

[houmark]

I did try this, and I didn't have any issue with factory reset, so that didn't interfere with this. The entire setup process was very smooth and communicative, so nice work, thanks a lot for that.

I enabled the Internal Share Uses Disk Root option, and everything went fine, but my Time Machine I wanted to continue to use the already existing AFP setup, so I removed it. Maybe I made a mistake there and should have tried to unmount that AFP in some way, but I was honestly a little bit confused because they were all called the same names.

I then spent quite some time trying to use the CLI command tool to set the destination into the existing user subfolder of the disk, like:
sudo tmutil setdestination -a /Volumes/"AirPort Disk"/ShareRoot/Users/"My Name"

I tried various combinations assisted by AI, which included also doing the direct SMB://, including the username and different types of variants, but all of them unfortunately came back to a similar error which is:

Destination password: 
Failed to mount smb://192.168.1.220/ShareRoot/Users/My Name (error 2)
The backup destination could not be added.
POSIXError(_nsError: Error Domain=NSPOSIXErrorDomain Code=2 "No such file or directory")

The above was a different variant I tried instead of the volumes approach, but no matter which approach I used, it would always fail with this same error code.

So that's kind of where I'm stuck right now, and I actually don't have my time capsule working with this SMB at this time, so I'm hoping for any additional tips to try before I accept defeat and set it up as a new destination and then just keep the old sparsebundle as a last resort should I ever need it. I did try just using the GUI of Time Machine, but it also seemed to want to only set it up from scratch again, and it didn't detect the existing sparse bundle.

Thanks in advance for any tips :)

[jamesyc]

Don't check "internal share use disk root", and deploy again

If you check that, then samba will share the entire disk. If you don't check that, it shares only the ShareRoot folder. I only added that option because a few users requested it; most people who use the Apple defaults will be fine with just sharing the ShareRoot folder, which is what Apple does.

[jamesyc]

The SMB error itself is interesting. What does the doctor/Checkup command say?