Jump to content

"root folder name doesn't match volume name" error


Recommended Posts

We recently moved our storage (xfs formatted volume) from one server (Linux CentOS 6) to another (Linux CentOS 7). Now, when backing up the same volume using Retrospect, everything is transferred to tape properly, but at the end the activity ends with an error:

		While scanning volume ,
			root folder name doesn't match volume name: root "", volume ""

Does anyone have a clue what that means and how to make Retrospect happy?

Retrospect Engine version is 16.1.2.102, because the latest one does not work, it crashes our Linux client on connect. Linux client is on its latest, 16.0.0.7.

Link to comment
Share on other sites

Well, if by "name" you mean that the volume should have a label - then it has.

[root@host ~]$ lsblk --fs /dev/sdn1
NAME FSTYPE LABEL         UUID                                 MOUNTPOINT
sdn1 xfs    inS<redacted> 8117289f-4d52-40b0-a018-1b64dc836d06 /mnt/inS<redacted>

 

Link to comment
Share on other sites

oleksiak,

Read the second post in this Windows Linux, Unix and Netware Clients thread.  If the CentOS 7—but with FreeBSD kernel (... 11.2 and 12.0 kernels)—is applicable to you, it looks like there was—at least experimentally—some kind of fix for the Retrospect Windows Engine that may not have made it into the Retrospect Mac Engine.  OTOH maybe that fix never made it into a later production release of the Retrospect Windows Engine.  I'd suggest PM'ing Xenomorph to find out if it did, and then contacting Retrospect Tech Support on that basis.  You may also (or instead—in case your OP-described bug was fixed in Engine 16.5 or 16.6) have to get your "it crashes our Linux client on connect" bug fixed for the Retrospect Mac Engine 16.6, though, unless you can get your OP-described bug fixed in an experimental version of 16.1.2.102 instead for 16.6.

Link to comment
Share on other sites

5 hours ago, oleksiak said:

Well, if by "name" you mean that the volume should have a label - then it has.

No -- I'm suggesting that it is successfully scanning, backing up, and verifying the storage volume, and is *then* failing to scan a nameless volume. What's the output from "lsblk --fs", without the device selector?

I'm assuming that, as with a Mac client, you can set things to back up the complete Linux box, only selected volumes, etc. Perhaps a previous "only the storage volume" tick-box was forgotten in the transfer to the new server.

Link to comment
Share on other sites

There are many nameless devices listed on lsblk output (these are StorNext LUNs), but they were present on previous system too.

I am not sure what tick-box you are referring to... In my backup I have only one specific volume selected as a source.

Most probably containerd (Docker) running on this Linux server is the culprit (Retrospect client is not installed inside container). I got a reply from Tech Support regarding 16.6.0.114 version crashing, they informed me there is no support for "docker configurations". If that's true, that would be a severe limitation.

Link to comment
Share on other sites

1 hour ago, oleksiak said:

I am not sure what tick-box you are referring to... In my backup I have only one specific volume selected as a source.

That's the information I was looking for...

So *if* you are only backing up one volume *and* that volume is backing up/verifying successfully *and* you can restore from the backup *and* you get the un-named volume error *and* Retrospect carries on regardless -- I'd just ignore it. If the error is causing other problems, eg killing the script while there are still other machines to process, re-arrange things so the erring machine is the last to be done.

If the error is truly killing the system, eg popping a dialog that must be dismissed before continuing, I'd look into script triggers and a GUI-targetted AppleScript to automatically dismiss the dialog so RS can continue.

Some things are easier to work round than to fix 😉

  • Like 1
Link to comment
Share on other sites

oleksiak,

This sounds like a problem I had in July 2017 (note to self: see Support Case #56419) when I experimentally upgraded my MacBook Pro from the Mac 14.0 Client to the Mac 14.1 Client.  When I re-Added the MBP as a "client" on Retrospect Mac 14, it began doing scripted Backup activities having the MBP as a Source so as to automatically include what I will call 3 Apple-created "hidden duplicate volumes" on the MBP—for which it got -1101 errors because the Engine couldn't see the "hidden duplicate volumes" on Backup script runs.  I discovered that there is now a Volumes dropdown in Sources->Options that specifies which volumes on a "client" should be backed up.  The dropdown defaults to All Volumes; I found I had to change the dropdown to Startup Volume to eliminate the "hidden duplicate volumes" (which are not shown with a disclosure triangle).  The Volumes dropdown is documented on page 40 of the Retrospect Mac 16 User's Guide,. 

Try changing the Options->Volumes dropdown in your Sources definition of your Linux "client" machine to Startup Volume—you may need to do a Sources Remove and re-Add and then re-checkmark in scripts.  I have a hunch that doing so may eliminate Retrospect Mac's trying to back up the Docker container.

 

Edited by DavidHertzberg
Revise first paragraph because the "hidden duplicate volumes" problem occurred in 2017 instead of 2019, and the Volumes dropdown _is_ documented in the UG
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  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.

Loading...
 Share

×
×
  • Create New...