Odd -1,101 error when finding backup set file over SMB. MacOS 10.15.1, Retro 16.5.1 (104)

[billbobdole]

Hey all, I have the Mac server 16.5.1 (104), on a 2012 Mac Mini 10.15.1 Catalina.  The catalog files are saved on a local SMB share.  Yesterday, the daily backup failed with a -1,101 (file/directory not found) when trying to access the catalog file on the SMB share.  Nothing has changed recently except the macOS & Retro updates.

 

Here is the mounted SMB share, with full r/w access:

 

And while the backup set show the file # and size, there are oddly no members or backups:

 

I attempt a test restore (which also shows no members/backups/greenBar), and then the -1,101 error:

 

I can confirm that adding a the share from within retrospect yields the same error:

 

Any ideas on where to start?  Retrospect immediately 'Locates' the backup set, but Rebuilding does nothing - no activity logged at all when I attempt one.  I've also tried removing the set from retro and re-adding, which it does successfully, but still replicates the error.  Nothing's awry on the macOS side - all diags check out, has been restarted, etc.

Thanks very much!  Sorry for all the pics

[DavidHertzberg]

billbobdole,

IMHO you are not being candid with us about what you are trying to do.  According to this PCMatic page, .rbf—shown in your first screenshot—is an extension that was used for File Backup Sets—which per page 34 of the Retrospect Mac 16 User's Guide "combine the Catalog File and backed-up files into a single file stored on a volume."  This old Knowledge Base article says, under "File Backup Sets", "Because a file’s resource fork is limited to 16 MB, the file will eventually grow too large for the file system. When this happens, Retrospect 5.0 or later will separate the catalog file from the data file to allow the file backup set to expand. The split catalog file will be named 'Backup Set Name.cat.'"  Moreover, because your .rbf file is referred to as "Backup Set" in your seventh screenshot, it appears you are trying to backup onto a File Media Set using Retrospect Mac 16—which may no longer work.

It sounds as if you will have to convert your old data to Disk Media Sets, which may or may not be possible.  If you recently upgraded to Retrospect Mac 16, you are entitled to 45 days free personalized help from Retrospect Tech Support—which isn't anyone on these Forums (we're volunteers).  You should phone (888) 376 -1078 extension 3.  However, you'll undoubtedly have to file a _candid_ Support Case, with your screen shots as attachments.

P.S.: This 2010 thread, in which you are the OP, confirms that my first-paragraph deduction is absolutely correct—you're still using File Media Sets.  You've been using a Retrospect trick described by twickland in this post in that same thread: New Media backups have enabled you to automatically create multiple File Media Sets whose name differs only in an appended square-bracket-surrounded "subnumber"—meaning those File Media Sets which you referred to in the next post in that thread as "new members"—on the same HDD.  My search of these Forums has disclosed no other mention of this  trick—especially a more-recent one.  The head of Retrospect T.S. has been around since 1994, so he may know whether the trick still works in Retrospect Mac 16.  Alternatively you could Private Message twickland, and see if he knows.  When I started using Retrospect again in 2015—after stopping backing up to tape 5 years before, a Tech Support person (named Alan; he left 2 or more  years ago) advised me not to use File Media Sets; so I have no knowledge of them.

P.P.S.: A reason what you're trying to do may not work is mentioned in this Knowledge Base article under "Details".  What you're trying to do may involve 32-bit data structures, and Retrospect Mac 16 eliminated their use—which may mean for File Media Sets as well as old OS X versions.  Ask Tech Support.

P.P.P.S.: By doing a Google Search (of history for my next post in this thread) using the ancient Retrospect term "storage set", I found a 2011 post that may solve your problem using your old trick! 😀   The OP for that thread (by an administrator who used the "handle" AshMan3 before the Forums messed it up) begins " I'm attempting to perform an incremental backup to the Storage Set and it fails with the error message 'Can't access Media Set iMac 2010-04-03, error -1101 (file/directory not found)'."  The solution post I've linked to quotes an administrator who went (no posts since 2013) by the "handle" CallMeDave.

P.P.P.P.S.: Have you read the "Catalina" sub-section under the "Technical  details" section in this Knowledge Base article?  Although it's termed a "folder", it sounds as if your SMB share must be given "Full Disk Access" in System Preferences->Security & Privacy->Privacy—as Nigel Smith alludes to  two posts below this one.  And the last sentence under "Version 16.5 Required" in this KB article requires FDA for "...  removable volumes and network volumes."

Edited November 27, 2019 by DavidHertzberg
OP must file a Support Case; P.S.: OP trying to _automatically_ generate _multiple_ File Media Sets ; P.P.S.: File Media Sets may involve 32-bit data structures; P.P.P.S.: possible solution per old "Retrospect trick"; P.P.P.P.S.: SMB "Full Disk Access"?

[DavidHertzberg]

billbobdole,

In case the Retrospect trick you're trying to use doesn't work anymore even with solutions in the P.P.P.S. or P.P.P.P.S. of my preceding post, here is how to replace it with facilities from 21st-Century ( 😀  ) Retrospect—as introduced with Retrospect Windows 7.5 in 2006 and added to Retrospect Mac 8 in 2009:

This post by you in a January 2010 thread starts out  "Every friday at 9pm, I have retro do a full backup of about 30 dept computers, which will finish sunday afternoon.  This full backup appends to an already existing backup set as a new member [meaning a new File Media Set per my post above]. The data file from the full backup is about 700 GB".  You can  replace this with a Recycle weekly Backup of the departmental computers onto a single "first-stage destination" Disk Media Set, which you will re-use each week.

Then during the week you can use a Copy Backup script—per pages 137-139 of the Retrospect Mac 16 User's Guide—to "copy this to a remote filestore which from there backs up to tape".  Because you are re-using the "first-stage" Media Set, that script can have the same source each week—so you won't have to do anything to it "manually".  Moreover, because Copy Backup by default copies only "active" backups to the "second-stage destination",  you don't have to Recycle the "first-stage destination" Media Set each week—so long as you don't set up a Grooming Option for it.

You can then use a Copy Media Set script—per pages 135-137 of the UG—to copy from that "second-stage destination" Disk Media Set to a "third-stage destination" Tape Media Set. If you checkmark the Match Source Media Set to Destination Media Set and Don't Add Duplicate Files to the Media Set options, you won't have to worry about duplication onto the "third-stage destination".

 

Edited November 27, 2019 by DavidHertzberg
Mention P.P.P.P.S. from my preceding post in first paragraph of this post; add phrase "second-stage destination" to third paragraph

[Nigel Smith]

On 11/21/2019 at 5:02 PM, billbobdole said:

Nothing has changed recently except the macOS & Retro updates.

Are you saying that "it worked before the OS and RS updates, but hasn't since"? Or has it worked since the updates but is now failing? If it's the former, try Support. If it's the latter:

Do a thorough disk check on your SMB server -- we've seen on these forums before where failing drives/corrupt volumes cause this error.

Are you manually mounting the SMB share, or is it done from RS as per your last screenie? I suggest you pick one or the other, to prevent conflicts.

Assuming the disk check passes, this feels like a permissions issue, RS being able to read but not write, so check your SMB server's logs for errors. And check you've granted RS "Full Disk Access" in System Preferences->Security & Privacy->Privacy.

While personally I'd prefer to use Disk Media, I can understand why the "self-contained" File Media format could be advantageous in some situations. And you should be OK capacity-wise, given that you've got larger -- both in size and file count -- listed.