timemachine error 512 and error 20 on macOS Ventura 13.4

blooper98

Dabbler
Joined
Jan 18, 2019
Messages
16
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

9Bsa6pA7ksdJUHnq-screenshot-2023-06-09-at-6-11-35-pm.png

(Not sure if needed) Add full control to the "everyone" ACL for flexible permissions, my attempt to prevent possible permissions errors
ebUi4KZP20Z8aucQ-screenshot-2023-06-09-at-6-13-36-pm.png

Enable Apple SMB2/3 Protocol Extensions on the samba service

6tY3ZqOSjiZpeAQA-screenshot-2023-06-09-at-6-15-55-pm.png

Add a Multi-user Time Machine samba share
CEs3bhfqIPISIhLK-screenshot-2023-06-09-at-6-14-16-pm.png

Add the new share as a Time Machine target on MacOS client
Screenshot 2023-06-09 at 6.18.41 PM.png

Screenshot 2023-06-09 at 6.18.57 PM.png

Screenshot 2023-06-09 at 6.19.14 PM.png

Screenshot 2023-06-09 at 6.19.30 PM.png


At this point I get an error

Screenshot 2023-06-09 at 6.20.03 PM.png

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
Screenshot 2023-06-09 at 6.23.55 PM.png

and I am able to create a test folder logged in as the same user (macmini0 in my case)
Screenshot 2023-06-09 at 6.24.48 PM.png

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

Explorer
Joined
May 21, 2017
Messages
56
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
 
Last edited:

blooper98

Dabbler
Joined
Jan 18, 2019
Messages
16
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
 
Last edited:

blooper98

Dabbler
Joined
Jan 18, 2019
Messages
16
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

Explorer
Joined
May 21, 2017
Messages
56
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

Explorer
Joined
May 21, 2017
Messages
56
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

Dabbler
Joined
Jan 18, 2019
Messages
16
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

Explorer
Joined
May 21, 2017
Messages
56
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

Explorer
Joined
May 21, 2017
Messages
56
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

Dabbler
Joined
Jan 18, 2019
Messages
16
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

Explorer
Joined
May 21, 2017
Messages
56
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,
 

help!

Explorer
Joined
Aug 3, 2023
Messages
57
Is this fixed guys? its not working for me like
 

RandomKiwi

Cadet
Joined
Sep 8, 2023
Messages
2
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

Cadet
Joined
Sep 8, 2023
Messages
2
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?
 
Top