timemachine error 512 and error 20 on macOS Ventura 13.4

[blooper98]

Hi All,

I'm hoping someone can help be get TimeMachine backups working on my macOS Ventura 13.4 Mac-mini to a TrueNAS Core 13.0-U5 server. I'm new to MacOS but previous forums topics mention bonjour errors, permission errors, and other non-conclusive errors that held them up. No luck so far finding them. I'd appreciate any insight into trouble shooting.

There's no explicit guide in the truenas core docs, so I've followed the one truenas scale, and tried to reproduce all my steps here:

Create a new dataset with the SMB share type checked

(Not sure if needed) Add full control to the "everyone" ACL for flexible permissions, my attempt to prevent possible permissions errors

Enable Apple SMB2/3 Protocol Extensions on the samba service

Add a Multi-user Time Machine samba share

Add the new share as a Time Machine target on MacOS client

At this point I get an error

which using the console app for details shows

Code:

com.apple.backupd.xpc: connection invalid
keychain blob version does not support integrity
Connecting to hdiejectd
Connected successfully
Failed to create '/Volumes/.timemachine/truenas._smb._tcp.local./F80D8BB2-06CF-41DE-B65B-4708D406F00B/TMB/5D6DE404-59ED-557F-953C-2BC6F8573220.sparsebundle', results: {
}, error: 512 error 512
Backup failed (20: BACKUP_FAILED_DISK_IMAGE_NOT_CREATED)

Despite the connection invalid error, truenas shows that a new sub volume has been created under the intended user which indicates the authentication was valid

and I am able to create a test folder logged in as the same user (macmini0 in my case)

and the permissions for the user dataset is

Code:

sudo getfacl macmini0            
Password:
# file: macmini0
# owner: macmini0
# group: timemachine
         everyone@:rwxpDdaARWcCos:fd----I:allow
            owner@:rwxpDdaARWcCos:------I:allow
            owner@:rwxpDdaARWcCos:fdi---I:allow
            group@:rwxpDdaARWcCos:------I:allow
            group@:rwxpDdaARWcCos:fdi---I:allow
group:builtin_users:rwxpDdaARWc--s:fd----I:allow
         everyone@:--------------:fd-----:allow

Does anyone know how to resolve this? Any additional insight or troubleshooting steps are appreciated.

 

[Mark Levitt]

I'm having the same problem setting up a new Macbook Air. I have a Time Machine share already configured and in use by multiple macs. However, I've tried to set up time machine on a recently purchased Macbook Air and it's failring with the same 512 error.

Edit: Just to add, both machines are logging into the share with the same user.

backupd: (TimeMachine) [com.apple.TimeMachine:General] Mountpoint '/Volumes/.timemachine/freenas._smb._tcp.local./1A04BEA0-3D59-4339-9959-56E4669DD355/TMBackup' is still valid
2023-06-18 17:20:54.783265+0100 0x11eec Info 0x250f3 502 0 backupd: (TimeMachine) [com.apple.TimeMachine:General] Mountpoint '/Volumes/.timemachine/freenas._smb._tcp.local./1A04BEA0-3D59-4339-9959-56E4669DD355/TMBackup' is still valid
2023-06-18 17:20:54.786472+0100 0x11eec Info 0x250f3 502 0 backupd: (TimeMachine) [com.apple.TimeMachine:DiskImages] Using a band size of 128 MB (max bands set to 16384, image size 2 TB)
2023-06-18 17:20:54.788009+0100 0x11eec Info 0x250f3 502 0 backupd: (TimeMachine) [com.apple.TimeMachine:DiskImages] Creating a sparsebundle using Case-sensitive APFS filesystem
2023-06-18 17:20:57.028138+0100 0x11eec Error 0x250f3 502 0 backupd: (TimeMachine) [com.apple.TimeMachine:DiskImages] Failed to create '/Volumes/.timemachine/freenas._smb._tcp.local./1A04BEA0-3D59-4339-9959-56E4669DD355/TMBackup/C1CE12B4-BE9D-5A93-8E07-5ACA94B463C7.sparsebundle', results: {
}, error: 512 error 512
2023-06-18 17:20:57.230618+0100 0x11eec Info 0x250f3 502 0 backupd: (TimeMachine) [com.apple.TimeMachine:General] Mountpoint '/Volumes/.timemachine/freenas._smb._tcp.local./1A04BEA0-3D59-4339-9959-56E4669DD355/TMBackup' is still valid
2023-06-18 17:20:57.452291+0100 0x11eec Info 0x250f3 502 0 backupd: (TimeMachine) [com.apple.TimeMachine:General] Unmounted '/Volumes/.timemachine/freenas._smb._tcp.local./1A04BEA0-3D59-4339-9959-56E4669DD355/TMBackup'

The machine where this fails and another where it's working fine are runing macOS Ventura 13.4.

TrueNAS is TrueNAS-13.0-U5.1

 

[blooper98]

Another instance of this error gave me some confidence this is not solely a configuration error on my part. To check if this is TN-Core specific and not some issue with my Mac and/or network, I installed an instance of Debian 12.0 (in a bhyve VM on my lan) using the default settings wherever possible. Note that this option is still required on bhyve and debian 12.

I setup a simple samba instance with the following: installing the required apt packages (samba and avahi-daemon), editing smb.conf using the samba wiki guide, adding a user with smbpasswd, then configuring my Mac to connect. The Time Machine backup initiates and completes without issue.

Here are my additions to the smb.conf, explicity, using Samba version 4.17.8-Debian

Code:

[global]
   vfs objects = fruit streams_xattr
   fruit:metadata = stream
   fruit:model = MacSamba
   fruit:posix_rename = yes
   fruit:veto_appledouble = no
   fruit:nfs_aces = no
   fruit:wipe_intentionally_left_blank_rfork = yes
   fruit:delete_empty_adfiles = yes

[timemachine]
    path = /home/%U/timemachine
    read only = No
    fruit:time machine = yes

 

[blooper98]

Similarly in a FreeBSD 13.1-RELEASE-p7 jail on my lan, using the net/samba416 package (commit 4.16.10_1) with avahi-daemon and samba_server enabled using the smb4.conf file allows for backup completion

Code:

[Global]
vfs objects = fruit streams_xattr
fruit:metadata = stream
fruit:model = MacSamba
fruit:posix_rename = yes
fruit:veto_appledouble = no
fruit:nfs_aces = no
fruit:wipe_intentionally_left_blank_rfork = yes
fruit:delete_empty_adfiles = yes

[TimeMachineBackup]
path = /home/%U/timemachine
read only = no
fruit:time machine = yes

 

[Mark Levitt]

I tried creating a new dataset and a new Time Machine share. The only options I changed from the default when I created the dataset was to change Share type to SMB. And then, when creating the share, I only changed Purpose to Multi-user time machine.

Configuring the Macbook Air to use the new share resulted in the exact same behaviour with the same error as the existing share.

Just for completeness, here is the output of testparm -s with the new share created:

freenas% sudo testparm -s
Load smb config files from /usr/local/etc/smb4.conf
Loaded services file OK.
Weak crypto is allowed

Server role: ROLE_STANDALONE

# Global parameters
[global]
aio max threads = 2
bind interfaces only = Yes
disable spoolss = Yes
dns proxy = No
enable web service discovery = Yes
kernel change notify = No
load printers = No
logging = file
map to guest = Bad User
max log size = 5120
nsupdate command = /usr/local/bin/samba-nsupdate -g
obey pam restrictions = Yes
registry shares = Yes
server multi channel support = No
server role = standalone server
server string = FreeNAS Server
unix extensions = No
idmap config *: range = 90000001-100000000
fruit:nfs_aces = No
rpc_server:mdssvc = disabled
rpc_daemon:mdssd = disabled
idmap config * : backend = tdb
directory name cache size = 0
dos filemode = Yes


[Media]
ea support = No
level2 oplocks = No
oplocks = No
path = /mnt/tank/media
read only = No
smbd max xattr size = 2097152
strict locking = Yes
vfs objects = zfs_space fruit streams_xattr zfsacl
fruit:resource = stream
fruit:metadata = stream
nfs4:chown = true
ixnas:dosattrib_xattr = false


[Storage]
ea support = No
path = /mnt/tank/storage
read only = No
smbd max xattr size = 2097152
vfs objects = zfs_space fruit streams_xattr zfsacl
fruit:resource = stream
fruit:metadata = stream
nfs4:chown = true
ixnas:dosattrib_xattr = false


[iTunes]
ea support = No
level2 oplocks = No
oplocks = No
path = /mnt/tank/iTunes
read only = No
smbd max xattr size = 2097152
strict locking = Yes
vfs objects = zfs_space fruit streams_xattr zfsacl
fruit:resource = stream
fruit:metadata = stream
nfs4:chown = true
ixnas:dosattrib_xattr = false


[homes]
browseable = No
ea support = No
path = /mnt/tank/home/%U
read only = No
smbd max xattr size = 2097152
vfs objects = zfs_space fruit streams_xattr zfsacl
fruit:resource = stream
fruit:metadata = stream
nfs4:chown = true
ixnas:dosattrib_xattr = false


[Recordings]
ea support = No
path = /mnt/tank/mythtv/recordings
smbd max xattr size = 2097152
vfs objects = zfs_space fruit streams_xattr zfsacl
fruit:resource = stream
fruit:metadata = stream
nfs4:chown = true
ixnas:dosattrib_xattr = false


[Shared]
ea support = No
guest ok = Yes
path = /mnt/tank/shared
read only = No
smbd max xattr size = 2097152
vfs objects = fruit streams_xattr ixnas zfs_core aio_fbsd
fruit:resource = stream
fruit:metadata = stream
nfs4:chown = true
ixnas:dosattrib_xattr = false


[TestSMBShare]
ea support = No
path = /mnt/tank/TestSMBShare
read only = No
smbd max xattr size = 2097152
vfs objects = fruit streams_xattr shadow_copy_zfs ixnas zfs_core aio_fbsd
fruit:resource = stream
fruit:metadata = stream
nfs4:chown = true
ixnas:dosattrib_xattr = false


[TMBackup]
ea support = No
kernel share modes = No
path = /mnt/tank/TMBackup/%U
posix locking = No
read only = No
smbd max xattr size = 2097152
vfs objects = tmprotect fruit streams_xattr shadow_copy_zfs ixnas zfs_core aio_fbsd
fruit:time machine max size = 2T
fruit:locking = none
fruit:time machine = yes
fruit:resource = stream
fruit:metadata = stream
nfs4:chown = true
ixnas:dosattrib_xattr = false


[TMTest]
ea support = No
kernel share modes = No
path = /mnt/tank/TMTest/%U
posix locking = No
read only = No
smbd max xattr size = 2097152
vfs objects = tmprotect fruit streams_xattr shadow_copy_zfs ixnas zfs_core aio_fbsd
zfs_core:zfs_auto_create = true
fruit:locking = none
fruit:time machine = yes
fruit:resource = stream
fruit:metadata = stream
nfs4:chown = true
ixnas:dosattrib_xattr = false

 

[Mark Levitt]

Hi,

It looks like creating a sparsebundle is where it's failing. I confirmed that, even on a different macOS client where Time Machine was working, creating a sparsebundle on a TrueNAS SMB share is failing.

I create a separate thread for this and hopefully if that issue is fixed, then setting up a new Time Machine will work again.

 

[blooper98]

With some confidence that the error is occurring due to the TN-Core specific config and repeatable errors from another user, looks like it's time to narrow down the problem setting. The creation of the sparsevolume fails on the macOS side.

Checking /var/log/samba4/log.smbd for errors on the TN-Core side...

Code:

[2023/06/19 00:13:40.809572,  1] ../../source3/rpc_server/srv_pipe_hnd.c:104(np_open)
  np_open: 'MsFteWds' is not a registered pipe!
[2023/06/19 00:13:43.681039,  0] ../../source3/modules/vfs_ixnas.c:2165(ixnas_fsetxattr)
  ixnas_fsetxattr: 5D6DE404-59ED-557F-953C-2BC6F8573220.sparsebundle: failed to reopen O_PATH descriptor: Is a directory
[2023/06/19 00:13:43.681144,  0] ../../source3/modules/vfs_fruit.c:2717(fruit_pwrite_meta_stream)
  fruit_pwrite_meta_stream: On-demand create [5D6DE404-59ED-557F-953C-2BC6F8573220.sparsebundle:AFP_AfpInfo] in write failed: Is a directory
[2023/06/19 00:13:43.681240,  1] ../../source3/smbd/smb2_setinfo.c:430(smbd_smb2_setinfo_send)
  smbd_smb2_setinfo_send: vfs_stat() of 5D6DE404-59ED-557F-953C-2BC6F8573220.sparsebundle:AFP_AfpInfo failed (No such file or directory)

which shows that there is a permission error being raised by the ixnas module when creating the sparse bundle.

The first error was addressed in this thread and may be a result of this system running samba since 12, so I ran

Code:

rm /var/db/system/samba4/private/passdb.tdb
midclt call smb.synchronize_passdb -job

but backups still fail the same way.

Since the vfs module ixnas is not available on other systems for testing I'll open a bug report.

 

[Mark Levitt]

Hi,

Yes, I'm seeing the same error:

[2023/06/19 19:20:59.349702, 0] ../../source3/modules/vfs_ixnas.c:2165(ixnas_fsetxattr)
ixnas_fsetxattr: u4test.sparsebundle: failed to reopen O_PATH descriptor: Is a directory
[2023/06/19 19:20:59.349953, 0] ../../source3/modules/vfs_fruit.c:2717(fruit_pwrite_meta_stream)
fruit_pwrite_meta_stream: On-demand create [u4test.sparsebundle:AFP_AfpInfo] in write failed: Is a directory
[2023/06/19 19:20:59.350099, 1] ../../source3/smbd/smb2_setinfo.c:430(smbd_smb2_setinfo_send)
smbd_smb2_setinfo_send: vfs_stat() of u4test.sparsebundle:AFP_AfpInfo failed (No such file or directory)

 

[Mark Levitt]

Found this bug fix for the vfs_ixnas module in ixsystem’s git repository: https://github.com/truenas/ports/pull/1287

“Metadata performance improvements in TrueNAS 13.0-U5 introduced a regression in ability to write alternate data streams to directories that were opened as pathrefs in Samba. This PR brings in fix to flags that are used to convert the O_PATH open into writable open.”

Sounds like it’s possibly related and so now it’s just a matter of waiting for the bug fix to make it to a release.

 

[blooper98]

Sounds like it’s possibly related and so now it’s just a matter of waiting for the bug fix to make it to a release.

Yup! They will release a fix in 13.0-U6 as in this ticket marked "high" priority

Since this was introduced in 13.0-U5, you could in theory revert to 13.0-U4 as a temporary work around.

 

[Mark Levitt]

Cool. I suppose you could boot into U4, set up the Time Machine so it creates the sparse bundle and does the initial backup, and then boot back to U5.1,

 

[Mark Levitt]

The test ixnas.so posted in the Jira ticket seems to have fixed the issue.

 

[help!]

Is this fixed guys? its not working for me like

 

[blooper98]

Is this fixed guys? its not working for me like

No, not until U13.0-6 is released

Since this was introduced in 13.0-U5, you could in theory revert to 13.0-U4 as a temporary work around.

 

[RandomKiwi]

I just had this problem against 13.0-U5.1; update to -U5.3 solved it. If any TrueNAS people read this, I'd like to put in a plug for more/better info in the release notes - there was NO mention in the release notes, or as far as I could see, in the referenced issues about TimeMachine failures being solved: "Metadata performance improvements in TrueNAS 13.0-U5 introduced a regression in ability to write alternate data streams to directories that were opened as pathrefs in Samba. This PR brings in fix to flags that are used to convert the O_PATH open into writable open." does NOT suggest that I should apply the fix when my TimeMachine backups are failing.

 

[RandomKiwi]

How is one supposed to know, without doing experiments, whether the ixnas.so included in a point update (e.g., -U5.x) actually contains the fix that is provided in the ixnas.so that is attached to this problem report? There does not appear to be a version number in the ixnas.so. How am I to know that if I replace the ixnas.so on my system with the one attached here that I'm not regressing some other change?