Mac OS 10.13 HighSierra (APFS?) client fails - Sierra works

Yes, the sparse file reading is messed up.

Relevant from the trace

5200/0x659d3: open("/Users/rene/Documents/UrBackupTest/Simply Red - Love Gave Me More.mp3\0", 0x1000000, 0x0) = 43 0
5200/0x63740: lstat64("/Users/rene/Documents/UrBackupTest/Simply Red - Love Gave Me More.mp3\0", 0x7000103984F0, 0x0) = 0 0
5200/0x659d3: fstat64(0x2B, 0x70000FEFCFE0, 0x0) = 0 0
5200/0x659d3: lseek(0x2B, 0x0, 0x4) = 0 0
5200/0x63740: lstat64("/Users/rene/Documents/UrBackupTest/Simply Red - Love Gave Me More.mp3\0", 0x7000103984A8, 0x0) = 0 0
5200/0x659d3: lseek(0x2B, 0x0, 0x3) = 7887081 0
5200/0x63740: stat64("/Users/rene/Documents/UrBackupTest/Simply Red - Love Gave Me More.mp3\0", 0x7000103984B8, 0x0) = 0 0
5200/0x659d3: lseek(0x2B, 0x7858E9, 0x4) = -1 Err#6\

Somehow this is the reverse from the Linux/POSIX API ( ). Does anyone have a support contract or something and can ask Apple about this?

Hi @uroni,
we have an Apple developer account in our company, not sure if this could help here somehow,
but I could try for sure.

Just can confirm now, too, that backups of files from Macs with 10.13 seem successful - but on restore,
all files which have been backed up after Upgrade to High Sierra … contain only zeros.
So this is a really high risk problem for us.

AFAIK the maintainers of Carbon Copy Cloner seem to have a lot of knowledge about APFS, e.g.

may be they answer your questions.

Apple doc about APFS seems not so much …

Best regards,

Fixing this is trivial – just remove the sparse file support from the Apple client.

I was hinting at the other option – Apple fixing the API such that it works the same as in Linux/FreeBSD, because there is no reason to make it inverse.

That’d be great for now - so we have a reliable backup again. Are you sure this is only a sparse file problem?
When I made my restore tests, there were zip files containing zeros, too - and IMHO these are no sparse files. Or can this be another problem?

So, how could I test this, can we try the next client beta with stable server, or is it needed to upgrade both server and client to beta versions?

Thank you very much and have a nice sunday.

may be a workaround for now. But no way back to HFS+ when on high sierra already …?

I don’t want to upgrade the mac to test on APFS because I have heard that MacOS 10.13 does not work in decembers :wink:

So how can we backup already upgraded High-Sierra-Macs using UrBackup atm?

I’ll publish a fixed version soon but won’t be able to test it.

Wrt. APFS: Can someone look into creating a script like this:

And again I cannot find any documentation about this.

Well, found the following things for now that seem related:

But there’s no apfs_snapshot utility like mentioned in the last link:

bash-3.2# ls -l /System/Library/Filesystems/apfs.fs/Contents/Resources/
total 6240
-rwxr-xr-x 1 root wheel 526784 Oct 25 18:37 apfs.util
-rwxr-xr-x 1 root wheel 529952 Oct 25 18:37 apfs_invert
-rwxr-xr-x 1 root wheel 1271328 Oct 25 18:37 apfs_preflight_converter
-rwxr-xr-x 1 root wheel 24704 Oct 25 18:37 apfs_stats
-rwxr-xr-x 1 root wheel 694560 Oct 25 18:37 fsck_apfs
-rwxr-xr-x 1 root wheel 1265504 Oct 25 18:37 hfs_convert
-rwxr-xr-x 1 root wheel 34672 Oct 25 18:37 mount_apfs
-rwxr-xr-x 1 root wheel 559248 Oct 25 18:37 newfs_apfs
-rwxr-xr-x 1 root wheel 520736 Oct 25 18:37 slurpAPFSMeta

Using the tmutil snapshots would be cool, but … may be this works only if another Time Machine volume is configured:

bash-3.2# /System/Library/Filesystems/apfs.fs/Contents/Resources/apfs.util
Usage: apfs.util [[-p][-k] /dev/diskXsYsZ]|[-s /dev/diskXsY]|[-R SNAPSHOT][-M dir][-S dir][-O path]
-p : probe for volume name
-k : get volume UUID
-s : set volume UUID(s) and container UUID to new random values
-R SNAPSHOT : set the volume to revert to the snapshot named by SNAPSHOT on next mount.
-M dir : flag the named directory as “maintain-dir-stats”.
-S dir : get the directory stats from dir.
-O path [optional fs name] : override the fstypename for apfs to be “hfs” (or the optional name given)
apfs.util [-D [get | set=yes | set=no] /dev/diskXsY] -D get : Get defragmentation setting for volume or container
-D set=yes : Enable defragmentation for volume or container
-D set=no : Disable defragmentation for volume or container
apfs.util -B
-B : bootstrap the root filesystem

So maybe we can put together the apfs_create_filesystem_snapshot script using these cli tools.

Cannot do the tests on a production system, tho - but I*ll try to setup a test machine with High Sierra. If I read it correctly, the apfs tools have been available since Sierra, so one could create an apfs volume using Sierra and make some tests ,

Can someone try if this one fixes this problem:

I’ve installed the 2.1.17 pkg on one client and just trying to get a backup started, will tell you later or tomorrow if it works.

To check if “/” is using apfs just used the following lines successfully:

if [ x$(df -T apfs | egrep " ${SNAP_MOUNTPOINT}$" | head -n 1 | tr -s " " | cut -d" " -f9) == x${SNAP_MOUNTPOINT} ] ; then

Great! 2.1.17 seems to work - just compared/restored some files.

For the snapshot script maybe this works somehow:

if [[ $TYPE == “apfs” ]]

    tmutil localsnapshot
    # TODO: ... some funny things to check date and hour of snapshot?
    SNAP_DEST="tmutil listlocalsnapshots / | tail -n1"

echo “Cannot create snapshot of file system with type $TYPE”
exit 1

here the output of tmutil commands regarding snapshots:

bash-3.2# tmutil | grep snap
Usage: tmutil delete snapshot_path …
tmutil compare [-@acdefghlmnstuEX] [-D depth] [-I name] snapshot_path
Usage: tmutil localsnapshot
Usage: tmutil listlocalsnapshots <mount_point>
Usage: tmutil listlocalsnapshotdates [<mount_point>]
Usage: tmutil deletelocalsnapshots <snapshot_date>
Usage: tmutil thinlocalsnapshots <mount_point> [purgeamount] [urgency]

Thank you very much for your quick client fix anyway!

You should be able to test this by creating a /Applications/UrBackup file with contents pointing to snapshot creation and destruction scripts:


I cannot see a command to remove a specific snapshot, though.

Hi, I am on holidays now, but as soon as I return I will test the new client for MacOS.

By then, I guess you already know how it works, but alas, I will test it thoroughly :slight_smile:

it works like this:

 tmutil deletelocalsnapshots <snapshot_date>

bash-3.2# tmutil localsnapshot
Created local snapshot with date: 2017-12-14-172436
bash-3.2# tmutil listlocalsnapshots /
bash-3.2# tmutil deletelocalsnapshots 2017-12-14-172436
Deleted local snapshot ‘2017-12-14-172436’

Great! Shouldn’t be much of a problem to put together two scripts with this I guess.

Well, have an iMac with High Sierra now for testing, hoping to find some time next week.

Dunno how to mount a snapshot, yet - or, how vs. where urbackup needs it?

It’s probably mounted already. We just need to find the path where it is mounted usually.

There seems at least some good documentation now:

May be the FDA problems on Mojave 10.14 could be worked around by using the local, hourly Time Machine snapshots for UrBackup?

That’s a documentation of the file system itself. Not about the utils to manage it. (I don’t want to write I file system driver to create a snapshot :wink: ).

Still no dice for tmutil