• [6.10] TimeMachine backups continue to fail "failed to attach using diskimages2" "operation not supported by device"


    wgstarks
    • Minor

    I first posted regarding this in the prerelease section here but just testing and reporting for 6.10. See the initial bug report for more details.

     

    Summary:

    TimeMachine completes one backup but then cannot mount that sparsebundle for future backups. This error is being reported by multiple unraid and synology users.

    • Like 1
    • Upvote 1



    User Feedback

    Recommended Comments



    I took a look at the time machine docker container and it doesn't appear to be doing much unraid isn't already going. I tried changing my smb-extra to match and no joy. Which makes me think this is a problem external to samba.

     

    So I tried changing my time machine share's export setting to no and instead of letting unraid configure samba to share it, configure the share myself in smb-extra, pointing the share at /mnt/disk2/Cadence TM instead of /mnt/user/Cadence TM. This bypasses the unraid process that manages which drive to put a particular file on, which means the entire share has to be on one drive and you can't use the cache. And TM started working. Haven't used it long enough to be sure, but if it keeps working, this might be a good work-around.

    Link to comment

    I just want to summarize my experiences with macOS Catalina and unRAID 6.10.3:

    -TimeMachine only does the initial fullbackup to unRAID shares mrked for TimeMachine. Later incremental backups do not work.

    -Access to shares slower than with 6.9.x - I disabled an reenabled macOS compatibility for SMB, but it did not help

    -having installed the TimeMachine container does not solve any problems, the problems get worse: the initial full backup starts but does finish, it just stops. Once it did finish, but subsequent incremental backups did not work

     

    I am sure that re-installing macOS is not instrumental in solving this issue due to the following observations:

    -people report that without macOS reinstall TimeMachine resumes to work after downgrading to 6.9.2

    -on the same Catalina TimeMachine works fine with a Synology, but not with unRAID 6.10.3

    -peple report that reinstalling macOS did not solve their problem

     

     

    Overall this is a highly unsatisfactory situation for me.

    I am just lucky to own a Synology, too, so I do have backups. I wanted to have it al consolidated on unRAID, though.

     

    • Upvote 2
    Link to comment

    Just to add another report to this... I am also experiencing this, exactly as described by others here:

    • Last successful Time machine backup was the day before I upgraded to 6.10.3 from 6.9.2.
    • I can add a new share and connect time machine to it, which then finishes its initial backup after which again it can not finish a single one anymore.
    • This happens independently of the Mac OS version it seams.
    • I tried all the mentioned ideas or workarounds here (except the downgrade) and none worked for me unfortunately.

     

    Actually the time machine backup of different machines is one of the two main reasons for having this unraid server so it would be really really appreciated if this bug got fixed! Thank you!

    • Upvote 2
    Link to comment
    1 hour ago, saber1 said:

    @SpaceInvaderOne just made a video about that.

    I will test this now. Hope it works:

     

     

    Thanks for the info, I'll also try it later today. What I find a bit weird is the setting for "enhanced Mac interoperability" (2:28), where it is set to "no" but still he can export the share as TimeMachine. For me I think I remember that the Time Machine option was never available when interoperability was set to no. Later in the video (11:22) it is activated however.

    Link to comment
    3 hours ago, Jonny13 said:

    What I find a bit weird is the setting for "enhanced Mac interoperability" (2:28), where it is set to "no" but still he can export the share as TimeMachine. For me I think I remember that the Time Machine option was never available when interoperability was set to no. Later in the video (11:22) it is activated however.

    Can say about the specific time stamps as I watch the video 12+ hours ago, but there are parts of the video with 6.10.3 and others with 6.9.2. It might explain it ?

    Link to comment

    I solved this issue adding these lines to the SMB Extras:

    [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

     

    Link to comment
    1 hour ago, UnKwicks said:

    I solved this issue adding these lines to the SMB Extras:

    I tried it several weeks ago. It takes no effect on my case.

    • Upvote 1
    Link to comment
    On 8/13/2022 at 9:53 PM, UnKwicks said:

    I solved this issue adding these lines to the SMB Extras:

     

    Thanks for sharing this UnKwicks, it prompted me to do some comparisons.

     

    I had a look at these compared to my Unraid 6.10.3 system with Enhanced macOS interoperability set to ON and with Time Machine shares exported.

     

    I found:

    • vfs objects = catia fruit streams_xattr - already in smb.conf via smb-shares.conf (under each share definition)
    • fruit:nfs_aces = no                              - already set in smb.conf via smb-names.conf
    • fruit:zero_file_id = yes                         - not set anywhere that I can find, but Samba default is YES
    • fruit:metadata = stream                      - already set in smb.conf via smb-names.conf, but set to NETATALK (which is                                                               the Samba default)
    • fruit:encoding = native                        - already set in smb.conf via smb-names.conf
    • spotlight backend = tracker                - not set anywhere that I can find

     

    So aside from the Spotlight setting, the only difference was that I did not have fruit:metadata = stream.

     

    I added this to my SMB Extras section...

     

    [Global]
    fruit:metadata = stream

     

    ... and I'm very happy to say that my Time Machine backups have resumed working (same MacOS devices, no other changes on their side).

     

    The fix is repeatable (remove the section, they break, put it back in and they work again).

     

    This is with leaving the system-generated smb-names.conf file as-is, so it's working despite the fruit:metadate = netatalk section in that file. Presumably since smb-extras.conf is included later in the smb.conf and so take precedence.

     

    I wonder if you could test just adding this one line to your SMB Extras section please @saber1?

    Link to comment
    On 8/14/2022 at 5:31 PM, Oldbean57 said:

     

    Thanks for sharing this UnKwicks, it prompted me to do some comparisons.

     

    I had a look at these compared to my Unraid 6.10.3 system with Enhanced macOS interoperability set to ON and with Time Machine shares exported.

     

    I found:

    • vfs objects = catia fruit streams_xattr - already in smb.conf via smb-shares.conf (under each share definition)
    • fruit:nfs_aces = no                              - already set in smb.conf via smb-names.conf
    • fruit:zero_file_id = yes                         - not set anywhere that I can find, but Samba default is YES
    • fruit:metadata = stream                      - already set in smb.conf via smb-names.conf, but set to NETATALK (which is                                                               the Samba default)
    • fruit:encoding = native                        - already set in smb.conf via smb-names.conf
    • spotlight backend = tracker                - not set anywhere that I can find

     

    So aside from the Spotlight setting, the only difference was that I did not have fruit:metadata = stream.

     

    I added this to my SMB Extras section...

     

    [Global]
    fruit:metadata = stream

     

    ... and I'm very happy to say that my Time Machine backups have resumed working (same MacOS devices, no other changes on their side).

     

    The fix is repeatable (remove the section, they break, put it back in and they work again).

     

    This is with leaving the system-generated smb-names.conf file as-is, so it's working despite the fruit:metadate = netatalk section in that file. Presumably since smb-extras.conf is included later in the smb.conf and so take precedence.

     

    I wonder if you could test just adding this one line to your SMB Extras section please @saber1?

     

    Adding "fruit:metadata = stream" to my SMB extras (as my only SMB extra) fixed my issue. Thank you for your help Oldbean56!

    Link to comment

    Glad to hear it worked for you @54lzy, but sorry to hear it didn't work for you @saber1.

     

    Just to check, because I noticed I said "I wonder if you could test just adding this one line to your SMB Extras section", did you actually add the [Global] too to your SMB Extras section? E.g.:

     

    [Global]
    fruit:metadata = stream

     

     

     

    Link to comment

    I'm sorry to say @oldbean57's fix did not work for me. First backup completes without issue but then there are no subsequent backups. Verification is even successful but still cannot create new backups. I'm on BigSur 11.6.8. I hope a fix can be found soon

    Link to comment
    3 hours ago, Oldbean57 said:

    did you actually add the [Global] too to your SMB Extras section?

    This is how my SMB Extras look a like:

     

    Bildschirmfoto 2022-08-18 um 21.07.06.png

     

    Nothing else.

    Edited by saber1
    Link to comment

    Cautiously optimistic this is now working!!  After wrestling with this for 3 days, the simple solution above of adding those 2 lines to the end of my SMB Samba extra configuration did the trick:

     

    [Global]
    fruit:metadata = stream

     

    PLUS, it seemed to run faster, as well.

     

    Nothing else changed… no Mac or Unraid reboot… it just worked, with several iterative backups thereafter.

     

    My config:

    • Unraid V6.10.3
    • Monterey V12.4
    • Apple M1 Pro

    Initial backup to dedicated share.

     

    Thanks @UnKwicks & @Oldbean57 !!

    • Like 1
    Link to comment

    I noticed something - if I disable encryption on the backup it works fine for the most part. Interesting. Can anyone else confirm this on their end?

    Link to comment

    Hi,

     

    I'm very pleased to hear this is helping some others, I wish it would work for all!

     

    I tried earlier with 6.11.0-rc3 as it includes a newer version of Samba (4.16.4) which has some bug fixes that I was curious if they would be the cause of the issue since 6.10. I'm afraid this did not help - my incremental Time Machine backups still did not without the "fruit:metadata = stream" parameter.

     

    I've not had need to delve in to this part of using Samba previously so I'm still learning, but from what I have read so far setting "fruit:metadata = stream" just tells the Samba fruit VFS module to pass handling metadata to the next VFS module, which I expect for most of us using "Enhanced macOS interoperability" means the "streams_xattr" module (e.g. we have "vfs objects = catia fruit streams_xattr" in each of our share definitions.

     

    Without this "fruit:metadata = stream" parameter taking precedence later via smb-extra.conf, the default Samba setting of "fruit:metadata = netatalk" is applied via smb-names.conf, meaning metadata is written in a way compatible with Netatalk (AFP).

     

    I wondered if this was perhaps something to do with the underlying file systems we are using to store backups (I use encrypted btrfs), but looking here, btrfs has a lesser capacity than XFS for storing extended attributes, so you'd think that streaming the attributes to the filesystem would cause issues rather than resolve them.

     

    Unless the issue is with the Netatalk-compatible metadata that was written during previous backups and now we're saying to use a different method, we're working around that issue?

     

    I've worked with computers long enough to suspect it's not a coincidence that this issue started with 6.10 and that included the version of Samba which was released to patch the vulnerability in the Netatalk-compatible resource and metadata implementation in vfs_fruit... That implementation received some changes, then we find that not using part of it helps with an issue that appeared since it was tweaked?

     

    It may still be interesting to compare the file system used by working and non-working implementations.

     

    Bit of a brain dump there in case it helps anyone else with their reasoning!

     

    @Jclendineng - Just saw your post come in: I've never used Time Machine backup encryption, so have had this issue without that enabled. (I do use Unraid file-system encryption instead).

     

     

    Link to comment

    Came here to post my working settings. 

    I just upgraded from 6.9.2 to 6.10.3. Had zero issues with my Time Machine.

    Originally when I went from 6.8 to 6.9.1, my Time Machine stopped working, and I made some changes to the config. I am using unassigned devices plugin to use Time Machine with external USB hard drive.


     

    [Time Machine]     
       ea support = Yes
       path = /mnt/disks/WD_My_Passport_25E2/Time_Machine/
       vfs objects = catia fruit streams_xattr
       valid users = timemachine
       write list = timemachine
       fruit:time machine max size = 3500 G
       fruit:encoding = native
       fruit:metadata = netatalk
       fruit:resource = file
       fruit:time machine = yes
       fruit:advertise_fullsync = true
       durable handles = yes
       kernel oplocks = no
       kernel share modes = no
       posix locking = no
       inherit acls = yes

    #disable SMB1 for security reasons
    [global]
       min protocol = SMB2

    #unassigned_devices_start
    #Unassigned devices share includes
       include = /tmp/unassigned.devices/smb-settings.conf
    #unassigned_devices_end

    • Like 1
    Link to comment
    On 8/27/2022 at 4:15 PM, sit_rp said:

    Came here to post my working settings. 

    I just upgraded from 6.9.2 to 6.10.3. Had zero issues with my Time Machine.

    Originally when I went from 6.8 to 6.9.1, my Time Machine stopped working, and I made some changes to the config. I am using unassigned devices plugin to use Time Machine with external USB hard drive.


     

    [Time Machine]     
       ea support = Yes
       path = /mnt/disks/WD_My_Passport_25E2/Time_Machine/
       vfs objects = catia fruit streams_xattr
       valid users = timemachine
       write list = timemachine
       fruit:time machine max size = 3500 G
       fruit:encoding = native
       fruit:metadata = netatalk
       fruit:resource = file
       fruit:time machine = yes
       fruit:advertise_fullsync = true
       durable handles = yes
       kernel oplocks = no
       kernel share modes = no
       posix locking = no
       inherit acls = yes

    #disable SMB1 for security reasons
    [global]
       min protocol = SMB2

    #unassigned_devices_start
    #Unassigned devices share includes
       include = /tmp/unassigned.devices/smb-settings.conf
    #unassigned_devices_end

     

    Hey @sit_rp, I was able to get time machine backing up to an unassigned drive by using your settings. I'm encountering an issue though where I'm unable to unmount the unassigned drive. Have you encountered this at all?

    Link to comment

    Hello there! 

    My first post here, please be patient! ;) I am just getting started with Unraid and I was having the same issue with Time Machine a few days ago.

     

    The issue for me:

    - First backup was made successfully

    - After that no following backups can be made. Time Machine starts preparing and stops after 1-2 minutes. The logs show "failed to attach using DiskImages2" error...

    - I played around with the .sparsebundle file a bit. I could access and mount the file via terminal, show information about it and even attempting to repair the file (no error found btw), but when I tried to mount it via Finder or try to show it's size in Finder, Finder freezes and I had to restart the computer to fix it. (Same happened in terminal when I did a "ls -l" in the share, but "hdiutil" worked fine..) 

     

    I tried every suggested workaround in this thread, without success, including:

    - different SMB configurations suggested in this thread and in smb wiki

    - adding the share manually via config file and verifying the actual config with `testparm -v`

    - using the Time Machine Docker image

     

    I was using MacOS 12.5 (or 12.6, I don't remember) and Unraid 6.10.3. After two days of testing (and multiple full backups taking hours...) I gave up and accepted that there is a bug in smb/Unraid/MacOS somewhere and I decided to wait for the fix.

     

    But today I upgraded to the Public Beta of Ventura (MacOS 13) and came back to the Time Machine issue. It is still not working, but there are new information in the log for Time Machine after the upgrade. Maybe somebody has an idea:

     

    2022-09-14 21:00:25  Starting manual backup
    2022-09-14 21:00:25  Attempting to mount 'smb://[email protected]_smb._tcp.local/timemachine'
    2022-09-14 21:00:25  Initial network volume options for 'timemachine' {disablePrimaryReconnect: 0, disableSecondaryReconnect: 0, reconnectTimeOut: 0, QoS: 0x0, attributes: 0x1C}
    2022-09-14 21:00:26  Configured network volume options for 'timemachine' {disablePrimaryReconnect: 0, disableSecondaryReconnect: 0, reconnectTimeOut: 30, QoS: 0x20, attributes: 0x1C}
    2022-09-14 21:00:26  Mounted 'smb://[email protected]_smb._tcp.local/timemachine' at '/Volumes/.timemachine/NAS._smb._tcp.local/BE2E64C3-5555-44C4-ACD3-630D8977B1BC/timemachine' (672.83 GB of 1.05 TB available)
    2022-09-14 21:00:26  Skipping periodic backup verification: not needed for an APFS sparsebundle
    2022-09-14 21:00:27  'MacBook Pro von Simon.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-09-14 21:00:27  Mountpoint '/Volumes/.timemachine/NAS._smb._tcp.local/BE2E64C3-5555-44C4-ACD3-630D8977B1BC/timemachine' is still valid
    2022-09-14 21:00:27  Checking for runtime corruption on '/Volumes/.timemachine/NAS._smb._tcp.local/BE2E64C3-5555-44C4-ACD3-630D8977B1BC/timemachine/MacBook Pro von Simon.sparsebundle'
    
    ### SO FAR THE SAME AS BEFORE, THE NEXT LINES ARE NEW ###
    
    2022-09-14 21:00:30  Failed to get name of volume with mountpoint 'file:///Volumes/.timemachine/NAS._smb._tcp.local/BE2E64C3-5555-44C4-ACD3-630D8977B1BC/timemachine/', error: Error Domain=NSCocoaErrorDomain Code=257 "Die Datei „timemachine“ konnte nicht geöffnet werden, da du nicht die Zugriffsrechte hast, um sie anzuzeigen." UserInfo={NSURL=file:///Volumes/.timemachine/NAS._smb._tcp.local/BE2E64C3-5555-44C4-ACD3-630D8977B1BC/timemachine/, NSFilePath=/Volumes/.timemachine/NAS._smb._tcp.local/BE2E64C3-5555-44C4-ACD3-630D8977B1BC/timemachine, NSUnderlyingError=0x60000240ba20 {Error Domain=NSPOSIXErrorDomain Code=13 "Permission denied"}}
    2022-09-14 21:00:30  Failed to get name of volume with mountpoint 'file:///Volumes/.timemachine/NAS._smb._tcp.local/BE2E64C3-5555-44C4-ACD3-630D8977B1BC/timemachine/', error: Error Domain=NSCocoaErrorDomain Code=257 "Die Datei „timemachine“ konnte nicht geöffnet werden, da du nicht die Zugriffsrechte hast, um sie anzuzeigen." UserInfo={NSURL=file:///Volumes/.timemachine/NAS._smb._tcp.local/BE2E64C3-5555-44C4-ACD3-630D8977B1BC/timemachine/, NSFilePath=/Volumes/.timemachine/NAS._smb._tcp.local/BE2E64C3-5555-44C4-ACD3-630D8977B1BC/timemachine, NSUnderlyingError=0x60000240b750 {Error Domain=NSPOSIXErrorDomain Code=13 "Permission denied"}}
    2022-09-14 21:00:30  Failed to create volume info from disk '<TMDisk: 0x7feef7064c00> '/Volumes/.timemachine/NAS._smb._tcp.local/BE2E64C3-5555-44C4-ACD3-630D8977B1BC/timemachine'', error: missingName
    2022-09-14 21:00:30  Failed to create volume info from disk '<TMDisk: 0x7feef7064200> '/System/Volumes/Data/home'', error: missingURLForRemounting
    
    ### FROM HERE IT IS THE SAME AS BEFORE ###
    
    2022-09-14 21:01:14  Failed to attach using DiskImages2 to url '/Volumes/.timemachine/NAS._smb._tcp.local/BE2E64C3-5555-44C4-ACD3-630D8977B1BC/timemachine/MacBook Pro von Simon.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-09-14 21:01:14  Cancelling backup because volume '/Volumes/.timemachine/NAS._smb._tcp.local/BE2E64C3-5555-44C4-ACD3-630D8977B1BC/timemachine' was unmounted.
    2022-09-14 21:01:14  Requested backup cancellation or termination
    2022-09-14 21:01:14  Waiting 60 seconds and trying again.
    2022-09-14 21:01:14  Backup cancelled (22: BACKUP_CANCELED)
    

     

    Also there are this lines in the logs multiple times, not sure if it is related:

     

    2022-09-14 20:59:03  '/Volumes/timemachine' does not support SMB FullFSync
    2022-09-14 20:59:03  Failed to create volume info from disk '<TMDisk: 0x7feef9026000> '/System/Volumes/Data/home'', error: missingURLForRemounting

     

    • Like 1
    • Upvote 1
    Link to comment
    2 minutes ago, Simon Edelmann said:

     

    I tried every suggested workaround in this thread, without success

    Did you try reverting Unraid to 6.9.2 and then testing if it worked? 

    Link to comment
    2 minutes ago, kubed_zero said:

    Did you try reverting Unraid to 6.9.2 and then testing if it worked? 

     

    Ah no, this is the only thing I didn't try yet.

     

    From everything I read here in this and the other threads regarding this bug, I am quite confident that reverting to 6.9.2 would fix the problem. But because it is a new NAS I don't need Time Machine to work there (now). I still have my old Time Machine backup working and I decided to wait for a fix before switching the backup to the new machine.

     

    I was hoping that the new logs from MacOS 13 maybe help some smb experts here to investigate further. ;) 

    • Upvote 1
    Link to comment
    On 9/7/2022 at 10:07 PM, shaihulud said:

     

    Hey @sit_rp, I was able to get time machine backing up to an unassigned drive by using your settings. I'm encountering an issue though where I'm unable to unmount the unassigned drive. Have you encountered this at all?

    I never unmount my drives. Have you tried to unmount it from CLI?

    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.