• backup disk does not support the required capabilities [Time Machine]


    Indmenity83
    • Closed Minor

    A picture is worth a thousand words; 

     

    - Running Unraid 5.7.0-rc5

    - Share named 'backup' exported as SMB time machine

    - After picking share in Time Machine and entering appropriate username and password for the share I'm told the disk does not support required capabilities. 

     

    Not sure what I'm doing wrong here, or if something is actually broken?

     

    Screen Shot 2019-03-02 at 10.03.59 PM.png




    User Feedback

    Recommended Comments

    Are you sure that 2GB (2048MB) is a large enough volume for your backup? Mine is much larger. I use 1TB (1000000MB).

    • Like 1
    Link to comment

    Whoops; that was not what I meant to do. But after changing it (to 2000000 and removing it completely) I still get the same error. 

    Link to comment
    11 minutes ago, Indmenity83 said:

    Diagnostics attached

    Thank you.  I think there might be a problem due to me trying to maintain compatibility with old AFP (netatalk) and new SMB way of using time machine.  Probably should have just ripped out all the AFP/netatalk support completely.

     

    Well, please capture output of this command.  It will include your actual share names, so if you don't want to post here, please send via PM.

    testparm -sv

    You could have this output to a file on a share if it makes it easier, for example, to flash:

    testparm -sv >/boot/testparm.txt

     

    Link to comment

     

    I had added the 'time-machine' share after the initial post as a test to see if it was just some client-side caching tied to the network name of the share. Both shares result in the same error. 

     

    [edit, output moved to attached file to save scrolling]

    output.txt

    Edited by Indmenity83
    Link to comment
    1 hour ago, Indmenity83 said:

    [edit, output moved to attached file to save scrolling]

    Thanks, well it does look correct 🙄

     

    Has this ever worked for you?

     

    As pointed out by @wgstarks googling the message, this seems to be a common problem.  First thing to verify is that nothing is out of the ordinary on the OS X side, check for example:

     

    https://discussions.apple.com/thread/8241168

     

    https://architectsecurity.org/2018/01/solved-time-machine-error-17-and-time-machine-backup-does-not-support-required-time-machine-capabilities/

     

    Next, in the Samba vfs_fruit documentation, there is this warning:

    "Be careful when mixing shares with and without vfs_fruit. OS X clients negotiate SMB2 AAPL protocol extensions on the first tcon, so mixing shares with and without fruit will globally disable AAPL if the first tcon is without fruit."

     

    This might happen, for example, if you have existing connections to Unraid SMB shares with the "Enhanced OS X interoperability" set to No, and then change this to Yes.

     

    • Upvote 1
    Link to comment

    Does Time Machine over SMB require a private share like AFP does/did? That's how I have my Time Machine share configured and it works fine.

    Link to comment

    Thanks, 

     

    I had TimeMachine backups on Unraid working prior to the AFP -> SMB changes (High Sierra I think that was?). I've never had it work since then. 

     

    I've got a backup running now to a USB device, I'll try copying the file over to Unraid and then picking the drive to see if that make any difference

     

    Quote

    Next, in the Samba vfs_fruit documentation, there is this warning:

    "Be careful when mixing shares with and without vfs_fruit. OS X clients negotiate SMB2 AAPL protocol extensions on the first tcon, so mixing shares with and without fruit will globally disable AAPL if the first tcon is without fruit."

     

    This might happen, for example, if you have existing connections to Unraid SMB shares with the "Enhanced OS X interoperability" set to No, and then change this to Yes.

     

    This is interesting ... I did upgrade an existing Unraid box and had to go enable "Enhanced OS X interoperability" and I certainly had an existing connection to Unraid SMB shares prior to making that change. 

     

    Would a restart of the MacOS machine reset the "first tcon" or is it more than that (if anybody knows). Either way, I'll make sure I restart my laptop when I get home and try again.

    Link to comment
    32 minutes ago, Taddeusz said:

    Does Time Machine over SMB require a private share like AFP does/did? That's how I have my Time Machine share configured and it works fine.

    I tried public, private and secured ... all had the same error message; so while I'm not sure if its still required, it is at least a system check that I believe happens after whatever is causing my current failure. 

    Link to comment

    Well here's an interesting observation; this may be a different but related issue. I'm not at home to fully test TimeMachine. 

     

    I had set a single "include disk" on the share in order to target a disk with a good amount of free space. As part of the testing suggested above, I created a .sparsebundle locally and tried to move it to the share and found that I get an error about there not being enough free space. In fact, I can't even create a folder in the share. 

     

    280746746_ScreenShot2019-03-05at9_38_30AM.png.762ca1ac5e8596dd797aae28db79abe4.png

     

    However, if I remove the single "include disk" then there are no issues adding content to the share. I've done some additional testing and anytime I set an "include disk" the share will not accept content UNLESS I select 'disk 1' as the included disk. Similarly, if I exclude disk 1 at all I cannot write to the share. 

     

    When I get home tonight I'll see if this free space issue is what was causing TimeMachine to throw the "does not support the required capabilities" error (TimeMachine doesn't see the share over VPN).

     

     

    Link to comment

    Closing this issue as backups appear to be working.

     

    I'll open a new thread for the include/exclude bug that was the root cause. 

    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.