Odd Synology issue with Arq

I do a daily data backup of certain folders on my MBP to a Synology on my network, using Arq. The destination folder is something like

/Volumes/SynologyHome/Destination

Today, Arq began failing, and reporting it could not find the destination. I can see the destination in Finder and I can navigate to the destination via a browser. It’s there.

So I start up a new destination (call it "Destination2) and went to configure it in Arq. Arq says it cannot find /Volumes/SynologyHome/Destination2, so I copied the path of that location from Finder and see that something has changed /Volumes/SynologyHome to /Volumes/SynologyHome-1/.

The latter works in Synology, but I don’t know what or why something in MacOS (or Synology OS, or perhaps death rays from Mars) changed it.

Have you perhaps added or edited a user?

Home is your home directory,
HomeS is you and everyone else

Nothing changed on the Synology.

Did you update to DSM 7 in between Arq back ups?

I’ll take that as a no. Did you bump up against a disk quota?

(Net, you had a new home folder created on the Synology, correct?)

What version of Arq?
How is the share mounted? SMB, AFP?

Actually, that info does t matter. I’ve had this happen before. The fix (which you probably know) is to unmount or reboot, delete/rename the existing folder in /Volumes, then mount again.
SynologyHome Already existed, so macOS appended a -1.

Why? I dunno. Didn’t get removed properly when unmountef, etc.

Maybe the same reason my iMac Pro saw itself on my network yesterday and decided it should now be Johns-iMac-Pro-3.

Did you establish more than one connection with multiple users like your personal one and an admin account or a dedicated user account for the backup connections?

The user’s home folders reside in /volume1/homeS/<user name> and will be mounted locally to /volume/home on macOS and other unix-based system.

I could imagine that adding -1 would be a way to resolve the conflict when two independent Synology users attempt to mount their home folder simultaneously.

Maybe you had your connection established via Finder and then arq established another one? :thinking:

  1. No. I did not update to DSM 7
  2. No. I have not reached a disk quota
  3. No. I do not have a new home folder on the Synology – as I said, nothing changed on the Synology
  4. No. I do not have multiple connections with multiple users

Yep, that’s the fix. There was a zero-byte /Volumes/home folder. Removing that and rebooting the MBP fixed it.

Thanks as always @johnATL

1 Like

So a mount-point conflict just without the second user :wink:

I’m just curious as to “who” made the second mount point?

I can see where the “MacBook-3” could be a remnant of a DHCP lease
timeout, but I have never had Synology create a duplicate mount point,
btrfs is supposed to be smarter than that…

I suspect Arq. (Which I continue to be confused as to why you folks with
Synologi(es)? use Arq and not the included Synology back up utilities)

What’s Arq’s secret sauce?

In this case, macOS would have made the second mount point in the /Volumes folder.
If you want to mount, say, home, and /Volumes/home already exists, then macOS will use /Volumes/home-1 to mount the share to.
Sometimes, for unknown reasons (unknown to me), macOS leaves a folder lying around, which can lead to this. Other software may also errantly create the folder, thinking it is copying to a mounted share. That can leave files in the /Volumes/xxxx folder, which macOS would not use to mount a share.
That’s my understanding.

1 Like

I agree that that the second mount point was likely not caused by MacOS.

As for “why Arq”. Well, it’s reliable whereas I find Synology software frequently unreliable. (Someone will reply to tell me they don’t have that experience. Cool. Bless them.)

1 Like

:laughing: I agree, the “it works for me” is very seldom productive,
and often just increases everyone’s frustration level.

2 Likes