• Time Machine backups failing 6.10 rc8 "Failed to attach using DiskImages2"


    wgstarks
    • Solved

    I'm submitting this in the hope that it gets fixed even though I suspect that it may be the result of the macOS 12.3.1 update. It actually started happening well before rc8 was released. Last successful backup was on April 30th. Now I can create a new share for time machine backups and the first backup will be successful. Subsequent backups will fail with an error in time machine "Failed to attach using DiskImages2".

     

    Time Machine log-

    2022-05-11 22:03:04  Cleared pending cancellation request
    2022-05-11 22:03:10  Not prioritizing backups with priority errors. lockState=0
    2022-05-11 22:03:10  Starting manual backup
    2022-05-11 22:03:10  Rejecting candidate mount point: /Volumes/TM_mini, not owned by root
    2022-05-11 22:03:10  Attempting to mount 'smb://[email protected]/TM_mini'
    2022-05-11 22:03:10  Mounted 'smb://[email protected]/TM_mini' at '/Volumes/.timemachine/10.0.1.20/DEFC5403-1530-4ACF-8A8C-004E23519E00/TM_mini' (420.71 GB of 1.05 TB available)
    2022-05-11 22:03:10  Initial network volume parameters for 'TM_mini' {disablePrimaryReconnect: 0, disableSecondaryReconnect: 0, reconnectTimeOut: 60, QoS: 0x0, attributes: 0x1C}
    2022-05-11 22:03:10  Configured network volume parameters for 'TM_mini' {disablePrimaryReconnect: 0, disableSecondaryReconnect: 0, reconnectTimeOut: 30, QoS: 0x20, attributes: 0x1C}
    2022-05-11 22:03:11  Skipping periodic backup verification: not needed for an APFS sparsebundle
    2022-05-11 22:03:11  'm1-mini.sparsebundle' does not need resizing - current logical size is 996.15 GB (996,147,200,000 bytes), size limit is 996.15 GB (996,147,200,000 bytes)
    2022-05-11 22:03:11  Mountpoint '/Volumes/.timemachine/10.0.1.20/DEFC5403-1530-4ACF-8A8C-004E23519E00/TM_mini' is still valid
    2022-05-11 22:03:11  Checking for runtime corruption on '/Volumes/.timemachine/10.0.1.20/DEFC5403-1530-4ACF-8A8C-004E23519E00/TM_mini/m1-mini.sparsebundle'
    2022-05-11 22:03:47  Failed to attach using DiskImages2 to url '/Volumes/.timemachine/10.0.1.20/DEFC5403-1530-4ACF-8A8C-004E23519E00/TM_mini/m1-mini.sparsebundle', error: Error Domain=NSPOSIXErrorDomain Code=19 "Operation not supported by device" UserInfo={DIErrorVerboseInfo=Failed to initialize IO manager: Failed opening folder for entries reading}
    2022-05-11 22:03:47  Failed to unmount '/Volumes/.timemachine/10.0.1.20/DEFC5403-1530-4ACF-8A8C-004E23519E00/TM_mini', Disk Management error: {
    2022-05-11 22:03:47  Failed to unmount '/Volumes/.timemachine/10.0.1.20/DEFC5403-1530-4ACF-8A8C-004E23519E00/TM_mini', error: Error Domain=com.apple.diskmanagement Code=0 "No error" UserInfo={NSDebugDescription=No error, NSLocalizedDescription=No Error.}
    2022-05-11 22:03:47  Waiting 60 seconds and trying again.
    2022-05-11 22:03:47  Cancelling backup because volume '/Volumes/.timemachine/10.0.1.20/DEFC5403-1530-4ACF-8A8C-004E23519E00/TM_mini' was unmounted.
    2022-05-11 22:03:47  Requested backup cancellation or termination
    2022-05-11 22:03:48  Backup cancelled (22: BACKUP_CANCELED)
    2022-05-11 22:03:48  Failed to unmount '/Volumes/.timemachine/10.0.1.20/DEFC5403-1530-4ACF-8A8C-004E23519E00/TM_mini', Disk Management error: {
    2022-05-11 22:03:48  Failed to unmount '/Volumes/.timemachine/10.0.1.20/DEFC5403-1530-4ACF-8A8C-004E23519E00/TM_mini', error: Error Domain=com.apple.diskmanagement Code=0 "No error" UserInfo={NSDebugDescription=No error, NSLocalizedDescription=No Error.}

     

    Current SMB extra config-

    #unassigned_devices_start
    #Unassigned devices share includes
       include = /tmp/unassigned.devices/smb-settings.conf
    #unassigned_devices_end
    #macOS config start
       server multi channel support = no
    #macOS config end
    #vfs_recycle_start
    #Recycle bin configuration
    [global]
       syslog only = Yes
       syslog = 0
       logging = 0
       log level = 0 vfs:0
    #vfs_recycle_end
    #macOS config start
       vfs objects = catia fruit streams_xattr
       fruit:nfs_aces = no
       fruit:zero_file_id = yes
       fruit:metadata = stream
       fruit:encoding = native
       spotlight backend = tracker
    
    [Media]
       path = /mnt/user/Media
       veto files = /._*/.DS_Store/
       delete veto files = yes
       spotlight = yes
    
    [mini_SMB]
       path = /mnt/user/mini_SMB
       veto files = /._*/.DS_Store/
       delete veto files = yes
       spotlight = yes
    
    [ccc_mini_backup]
       path = /mnt/user/ccc_mini_backup
       veto files = /._*/.DS_Store/
       delete veto files = yes
       spotlight = yes
    
    [ccc_raid1_backup]
       path = /mnt/user/ccc_raid1_backup
       veto files = /._*/.DS_Store/
       delete veto files = yes
       spotlight = yes
    #macOS config end

     

     

    brunnhilde-diagnostics-20220511-2350.zip




    User Feedback

    Recommended Comments



    I have exactly the same problem, with the same macOS version 12.3.1, same SMB extra config the same error int Time Machine logs.

    Link to comment
    17 minutes ago, muzo178 said:

    I have exactly the same problem, with the same macOS version 12.3.1, same SMB extra config the same error int Time Machine logs.

    I suspect it has something to do with macOS 12.3.1 but only because the backups started failing right after the update. I've seen a few other reports with the same error and all on 12.3.1.

    Link to comment

    Updated to macOS 12.4 earlier this evening. Still getting the same error though. 🙁

    Looks like the update was primarily to address issues with Apple's new $5,000,000 monitor. 😁

    • Like 1
    Link to comment

    same issue here, could no longer connect to my TimeMachine share and when remove the disk and look again for disk, nothing shows up. Was working on previous versions of 6.10.

     

    Actually, can't seem to connect to any SMB shares on Unraid from my Mac. I also did the 12.4 update this evening and it's broken both ways.

     

    **Update - I was able to mount the TimeMachine share manually in finder using smb://nicknas2.homenet (DNS domain on my router). It had previously been using nicknas2.local which doesn't appear to be working anymore. After manually connecting to the share and re-associating the disk in TimeMachine, it seems to have started trying to back up. Fingers crossed...

     

    **Update 2 - the backup ran to completion so now it's using the unraid server name with my router's DNS domain instead of .local. Will keep an eye on it

    Edited by nickp85
    Link to comment
    20 hours ago, nickp85 said:

    **Update 2 - the backup ran to completion so now it's using the unraid server name with my router's DNS domain instead of .local. Will keep an eye on it

    Was this an initial backup? 

    Link to comment
    2 minutes ago, wgstarks said:

    @nickp85 Please confirm that you have had multiple successful backups and if so could you post the contents of your SMB extras.

    Yes multiple successful backups including a large one after installing 12.4. Nothing extra in my SMB options. I can confirm though I cannot browse through Finder for my Unraid shares. I have to use the Go menu to manually connect to them. Also, .local is not working anymore for some reason so I am using the DNS name configured on my router to reach the server. I manually connected to the TimeMachine share and then added the disk. Once I did that, it can find it again each time. My TimeMachine share is set to private but not hidden.

     

    #unassigned_devices_start
    #Unassigned devices share includes
       include = /tmp/unassigned.devices/smb-settings.conf
    #unassigned_devices_end
    #vfs_recycle_start
    #Recycle bin configuration
    [global]
       syslog only = Yes
       syslog = 0
       logging = 0
       log level = 0 vfs:0
    #vfs_recycle_end

    Link to comment
    33 minutes ago, nickp85 said:

    I have to use the Go menu to manually connect to them. Also, .local is not working anymore for some reason so I am using the DNS name configured on my router to reach the server. I manually connected to the TimeMachine share and then added the disk. Once I did that, it can find it again each time. My TimeMachine share is set to private but not hidden.

    Thanks. It doesn't appear that your issue was related to the one posted here since yours was a connection problem rather than failing to mount the sparsebundle image. I will try deleting my mac configurations in smb extras and see if that fixes my issue.

    Link to comment

    @nickp85

    Are any of your macs using an M1 chip or are they all Intel? The more I dig into the smb settings the more I start to think this is a bug with M1.

    Link to comment
    Just now, wgstarks said:

    @nickp85

    Are any of your macs using an M1 chip or are they all Intel? The more I dig into the smb settings the more I start to think this is a bug with M1.

    I have one Mac and it’s an M1 Max

    Link to comment
    4 minutes ago, nickp85 said:

    I have one Mac and it’s an M1 Max

    Thanks. I'm still not sure about the M1 though. I see quite a few online posts regarding M1 TM problems. I tried your settings and still can't complete more than a single backup.

    Link to comment

    I was able to resolve this issue by re-installing macOS 12.4, deleting the existing TM backup and creating a new one. It appears that the problem wasn't related to unRAID.

    Link to comment

    I ran into this issue.  I ended up deleting ALL local snapshots, which appears to be working (running right now).  Unfortunately, I had deleted all existing Time Machine backups on my Unraid box before I attempted this.  My guess is that Unraid is not at fault here, but I'm posting in case others run into this issue.  My suggestion would be to delete all local snapshots and then see if it begins working.

    Link to comment

    I was facing exactly the same issue. Time Machine creates the initial backup with no problems. If you start a new backup run, it fails with a umount problem at a certain point.

     

    The solution for me was to adjust the SMB settings (I added the "Global" section):

    #unassigned_devices_start
    #Unassigned devices share includes
       include = /tmp/unassigned.devices/smb-settings.conf
    #unassigned_devices_end
    #macOS config start
    [Global]
       vfs objects = catia fruit streams_xattr
       fruit:nfs_aces = no
       fruit:zero_file_id = yes
       fruit:metadata = stream
       fruit:encoding = native
       spotlight backend = tracker
    #macOS config  end

     

    This post helped me to solve the problem:

     

    • Like 1
    Link to comment
    1 hour ago, usefulsolutions said:

    The solution for me was to adjust the SMB settings (I added the "Global" section):

    I can’t check my system right now (not at home) but I’m fairly sure all these are default in latest stable release.

    Link to comment

    Just wanted to say I had this issue on both Intel and M1 Macs. Time Machine backups to Unraid were going swimmingly, with the Unraid share hosting an APFS sparseimage. I'm not sure if it was the Unraid 6.10 update or MacOS 12.3/12.4 or just bad timing, but then all the computers stopped being able to back up a month or so ago. I was able to make first (non-incremental) backups without issue, but subsequent incremental backups after that did not work. I had the same MacOS console issues as mentioned above: "Operation not supported by device" UserInfo={DIErrorVerboseInfo=Failed to initialize IO manager: Failed opening folder for entries reading}

     

    I had tried deleting the local snapshots on each Mac as well, to no avail. For reference, that's "tmutil listlocalsnapshots" to find the snapshot names and then "tmutil deletelocalsnapshots <snapshot-name>" to actually delete them. 

    Anyway, I applied the SMB Extra Config settings as mentioned above, and then re-attempted the incremental backups. Success! (Update: Time Machine now works on two of the three Macs. The last one still gets the "Failed opening folder for entries reading" error) The following SMB Extras config seems to have done the trick:

     

    [Global]
       vfs objects = catia fruit streams_xattr
       fruit:nfs_aces = no
       fruit:zero_file_id = yes
       fruit:metadata = stream
       fruit:encoding = native
       spotlight backend = tracker

     

    I did browse through the documentation pages to understand what these were doing  https://www.samba.org/samba/docs/current/man-html/vfs_fruit.8.html  https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html and the only callout I have is that the zero_file_id setting is yes by default, and may not be necessary. The rest of the options check out, though I'm not sure why this combination of options makes Time Machine work. I saw another post say that just setting two of these worked: 

     

    As a sidenote, I DID see that https://wiki.unraid.net/UnRAID_6/Configuring_Apple_Time_Machine recommends having a separate share per computer, but that seems to be outdated (bad?) advice and perhaps should be changed. I've got three Macs backing up to the same Time Machine share with no issues.

    Edited by kubed_zero
    Not working in all cases :(
    Link to comment

    It's pretty obvious that Apple made changes in the SMB implementation of macOS that seem to cause these issues.
    Its not Unraids nor Sambas fault. My temporary solution is to run a Netatalk/AFP server via a VM that gets the TimeMachine share passed through. With this, the incremental Time Machine backup works properly again. Also the already existing backups which were transferred before remain since only the network protocol is changed.

    I'm using Fedora since its using the latest version of netatalk which has some security fixes.
    This is only a temporary solution since AFP is insecure and was depreciated by Apple years ago but for home usage it's fine I guess.

    • Confused 1
    Link to comment
    Just now, T4ke said:

    It's pretty obvious that Apple made changes in the SMB implementation of macOS that seem to cause these issues.
    Its not Unraids nor Sambas fault

    I'm not sure I follow. If that were the case, why (in my setup) does upgrading to 6.10.x break backups, but reverting to 6.9.2 100% of the time fix backups? 

     

    1 minute ago, T4ke said:

    This is only a temporary solution since AFP is insecure and was depreciated by Apple

    Yep, I wanted to avoid going back to using an AFP share because of Apples deprecation of it. 

    Link to comment
    1 minute ago, kubed_zero said:

    I'm not sure I follow. If that were the case, why (in my setup) does upgrading to 6.10.x break backups, but reverting to 6.9.2 100% of the time fix backups? 

     

    Maybe there are some incompatibilities between Apples latest changes in their SMB stack and the different Samba versions of Unraid, that would be my first guess. In my statement I referred to postings in many different forums (Apple, Synology, iX Systems, etc), whose TM users all describe the same problem so I highly doubt that its a problem with Unraid. Most likely Apple is doing is own thing again, wouldn't be the first time.

    Link to comment
    1 minute ago, T4ke said:

    incompatibilities between Apples latest changes in their SMB stack and the different Samba versions

    Yeah, this could definitely be the case. I agree completely that Apple could be going off the rails in how things are built. But considering upgrading the server causes the breakage while the Apple device stays the same, and the Time Machine functionality in Unraid is built exclusively for Apple devices, I would have hoped that Limetech could have pinned the Samba version on something functional (or at least tested it in 6.10 to a thorough degree). 

     

    It's not a good look for Limetech if upgrades to 6.10.x result in failures of core functionality such as the built-in Time Machine backups, and then a reversion to the previous stable release can fix any issues seen. That's just my two cents, though I think I'm not alone in that sentiment.

    At some point in the next few weeks I'm going to try experimenting with installing 6.10.3 and then modifying my Go script to:

    • Stop the Samba process, I think with "/etc/rc.d/rc.samba stop"
    • Install the Samba version from 6.9.2 and hopefully overwrite the default version. I found 6.9.2 used version 4.12.14, as opposed to 4.15.7 in 6.10.3
    • Start the Samba process, I think with "/etc/rc.d/rc.samba start"
    • See if initial and then incremental backups still work

    I'd also want to try rolling forward and seeing if Samba 4.16.x packages would work, which should be straightforward to test once this Go script stuff is in place. 

    If anyone else gets a chance to do this, please share your results! It will be curious to see if the Samba package upgrade broke the functionality between 6.9 and 6.10, or if it was kernel-related modification, or something else. 

    Link to comment

    LimeTech doesn’t directly support time machine backups. They use the vfs_fruit package for this. Vfs_fruit attempts to maintain compatibility between SMB Linux, SMB Apple and Samba but obviously this is a bit of a slippery snake. Any changes to any of these will break things and it might be a while before updates are tested and released to fix the issues. Not to mention the fact that Time Machine has always been somewhat unstable (mine started working just because I re-installed it). I’m sure that updated packages are available LT will include them in unRAID. The TimeMachine docker is also an option. It supports SMB and AFP.

    • Confused 1
    • Upvote 1
    Link to comment



    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.
    Note: Your post will require moderator approval before it will be visible.

    Guest
    Add a comment...

    ×   Pasted as rich text.   Restore formatting

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.


  • Status Definitions

     

    Open = Under consideration.

     

    Solved = The issue has been resolved.

     

    Solved version = The issue has been resolved in the indicated release version.

     

    Closed = Feedback or opinion better posted on our forum for discussion. Also for reports we cannot reproduce or need more information. In this case just add a comment and we will review it again.

     

    Retest = Please retest in latest release.


    Priority Definitions

     

    Minor = Something not working correctly.

     

    Urgent = Server crash, data loss, or other showstopper.

     

    Annoyance = Doesn't affect functionality but should be fixed.

     

    Other = Announcement or other non-issue.