restore root file with tmutil

I'm not familiar with how Time Machine on a NAS works but I'm looking at a Time Machine backup I have on a USB external drive and I can access backups of /var/root by using sudo(8), and didn't need to mess with special mount commands or SIP:

$ sudo ls /Volumes/.timemachine/B5557776-FA71-48D9-B1E9-442B2BB5D0ED/2025-07-15-015123.backup/2025-07-15-015123.backup/Data/private/var/root
.CFUserTextEncoding	Downloads		Movies
.forward		Library

I was then able to restore some file from it with tmutil(8):

$ sudo tmutil restore -v /Volumes/.timemachine/B5557776-FA71-48D9-B1E9-442B2BB5D0ED/2025-07-15-015123.backup/2025-07-15-015123.backup/Data/private/var/root/.CFUserTextEncoding ~/testrestore
Copying file . ...
3 bytes for .
Total copied: 0.00 MB (3 bytes)
Items copied: 1

This was on a USB drive mounted with the regular automount system. I assume mounting a network drive with Finder would work similarly.

The only thing that was tricky is that /var/root is currently a symlink to /private/var/root (at least on macOS 15.5) so you have to access the backup of /private/var/root.

You might also need to give your terminal app Full Disk Access in System Settings.

So, there are actually a few different things at work here. First of the errors here:

/usr/local/mnt: No such file or directory

...means exactly what it sounds like. You specified the mount target (the point the new file system would attach on "your" file system) as "/usr/local/mnt/" and that directory either does not exist or you don't have permission to it. That's what I'd expect, as that's not a standard macOS directory, so it won't exist unless you create it. The solution is to create the directory, change the permissions, or pick a new directory.

I'm not familiar with how Time Machine on a NAS works

I believe we still create disk images, which are then mounted and treated as local backup target volumes. That means there are actually two permission systems at work here:

1. The permission of the smb volume the NAS device shares.

2. The permission of the TimeMachine disk image.

That difference is important, because it leads to the difference in behavior between this case:

This was on a USB drive mounted with the regular automount system.

When mounting a local device (disk image, USB device, etc.), "your" computer has full control over how the permissions of the volume being mounted are actually handled/interpreted. The behavior default for disk images and external volumes (like USB drive) is the "Ignore ownership on this volume" setting, which corresponds to the mount flag "-o noowners".

https://support.apple.com/en-bw/guide/mac-help/mchlp1204/mac

I assume mounting a network drive with Finder would work similarly.

When mounting a network volume, the network server has final control over your access to the files it's shared.

In the case of TimeMachine backups, both of these systems are involved- the NAS server controls whether or not you're able to access the DiskImage, but the mount of the DiskImage itself is a "local" mount, so the local machine controls how the permissions of the DiskImage mount.

I was then able to restore some file from it with tmutil(8):

tmutil should work fine; however, you can also mount the disk image "directly" and pull files out of it by hand.

Must I defeat SIP to do this?

I don't see how SIP would be involved with this at all. SIP is primarily used to protect the integrity of the system itself, not user data, so I'm not aware of us marking any "user data" as SIP protected, including data that was directly created by the root user.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware