Lose Connection To Nas Volume

[Guest Toolman1848]

I frequently lose connection to the Shares (Sources) on my NAS disk. The Share are listed in the Sources pane, with "~" preceding the name of the Share. I see no way to get that Share recognized other than to remove it and then re-add it. Why is this happening? It is the one frequent problem I encounter resulting in backups no proceeding.

[f30e6e60-a263-4d69-8f60-c92703669308]

I frequently lose connection to the Shares (Sources) on my NAS disk.

 

More and more specific information, please.

[Guest Toolman1848]

More and more specific information, please.

 

 

I am using OS 10.6.7 on a Mac Pro 2x2.8 GHz Quad-Core running as the Server for Retrospect 8.2

 

I have a 2TB Iomega Home Media Network Drive attached to my network. I have several "shares" on that drive. Using the Console of Retrospect, I have added these shares as sources. I added these shares using the "Name" that I assigned to this external network drive, but I can also add them using the IP address for the drive. It seems that Retrospect prefers the IP address but I have succeeded in getting the Name (nas-hd1) recognized. I use a password to access the NAS drive. I have created schedules for running backups for each of the shares.

 

However, when it is time for a scheduled backup, if Retrospect cannot find the Share, then it puts the Share source offline and that is designated with the name of the share preceded by the "~" symbol. That Share is now offline and cannot be accessed for the backup.

 

I have found no way to get that share to go "online" without going back to the process of adding it as a share and then removing the offline share, then rechecking my schedules to make sure this newly added share is the source for the scheduled backup.

 

What more detail do you or anyone else need?

 

Thanks

Edited May 3, 2011 by Toolman1848

[f30e6e60-a263-4d69-8f60-c92703669308]

Using the Console of Retrospect, I have added these shares as sources.

Have you also mounted these shares on the Desktop of the Retrospect Engine host machine as a regular user?

 

If so, that's the cause of your problem.

 

 

Dave

[Guest Toolman1848]

Have you also mounted these shares on the Desktop of the Retrospect Engine host machine as a regular user?

 

If so, that's the cause of your problem.

 

 

Dave

 

 

I do mount the volumes (shares) so I can use them. So you are saying that if a Share is mounted to the server, then Retrospect considers it offline? If so, that seems to me to be a design flaw. After all, these shares exist to be used thus, requiring also an occasional backup.

[f30e6e60-a263-4d69-8f60-c92703669308]

If so, that seems to me to be a design flaw

If so, it's a flaw in how Unix works.

 

OS X does not allow a volume with the same name to be mounted more then once. When you mount a remote share, it is abstracted as /Volumes/nas-hd1/ .

When you then ask Retrospect to mount the same share at the same time, OS X gives it a different name in order to avoid the catastrophic possibility that this volume, while showing the same name as the one already mounted, is actually an entirely different volume being shared in another way. So it is represented to the operating system as /Volumes/nas-hd1-1/ .

 

Retrospect tracks volumes by its path, which is the correct thing for it to do as the Engine is a unix daemon and not a Login Window application. So if you have configured Retrospect to look for a volume with one name and then you force OS X to change that volume's name before Retrospect can see it, there's gonna be an error.

 

If you are using the Engine host machine as a workstation, create a share dedicated to acting as your Disk Media Set Member, and use that volume exclusively for that purpose.

Edited May 4, 2011 by CallMeDave

[Guest Toolman1848]

If so, it's a flaw in how Unix works.

 

OS X does not allow a volume with the same name to be mounted more then once. When you mount a remote share, it is abstracted as /Volumes/nas-hd1/ .

When you then ask Retrospect to mount the same share at the same time, OS X gives it a different name in order to avoid the catastrophic possibility that this volume, while showing the same name as the one already mounted, is actually an entirely different volume being shared in another way. So it is represented to the operating system as /Volumes/nas-hd1-1/ .

 

Retrospect tracks volumes by its path, which is the correct thing for it to do as the Engine is a unix daemon and not a Login Window application. So if you have configured Retrospect to look for a volume with one name and then you force OS X to change that volume's name before Retrospect can see it, there's gonna be an error.

 

If you are using the Engine host machine as a workstation, create a share dedicated to acting as your Disk Media Set Member, and use that volume exclusively for that purpose.

 

 

Thank you for the update, and I now understand a little better how Retrospect handles remote shares but I do not see why it is necessary to do it this way since it can also backup local harddrives which are mounted. But given it works this way, I do not see how I can use my shares for work, which requires mounting, but also assign a different name for the same shares for Retrospect purposes. I really do not want to duplicate my files, once to the working shares and once to the Retrospect share. OR, am I missing something here in my understanding.

[f30e6e60-a263-4d69-8f60-c92703669308]

I do not see why it is necessary to do it this way since it can also backup local harddrives which are mounted.

 

While Retrospect can see a physically attached external hard drive's volume(s) when there is a user logged in to a Window Server session in OS X desktop, that volume will become unmounted (and unavailable) when the user logs out (only OS X Server will keep attached drives available without a user logged in). But in any case, the path to the volume won't change; it will always be /Volumes/Foo/

 

But the security model of OS X doesn't allow a remote volume mounted (and therefore authenticated) by one process to be seen/used by another. If user ID 501 mounts the volume in the Finder, RetrospetEngine as user 0 won't see it without mounting the drive itself, leading up to the name change. It's a feature, but one that doesn't play nicely with trying to do three different things on the same computer at the same time.

 

If you need to work this way you'll probably need to unmount the remote share before your Retrospect Script is scheduled to run; that's assuming you Added the Source to Retrospect before/without mounting it as another user, so the path Retrospect stores is what you want (/Volumes/Foo/); reference the Path field of the Overview section of the Summary tab of the Sources window to see what Retrospect will be using, and compare that if necessary against what you see from a 'mount' command in Terminal.

[Guest Toolman1848]

While Retrospect can see a physically attached external hard drive's volume(s) when there is a user logged in to a Window Server session in OS X desktop, that volume will become unmounted (and unavailable) when the user logs out (only OS X Server will keep attached drives available without a user logged in). But in any case, the path to the volume won't change; it will always be /Volumes/Foo/

 

But the security model of OS X doesn't allow a remote volume mounted (and therefore authenticated) by one process to be seen/used by another. If user ID 501 mounts the volume in the Finder, RetrospetEngine as user 0 won't see it without mounting the drive itself, leading up to the name change. It's a feature, but one that doesn't play nicely with trying to do three different things on the same computer at the same time.

 

If you need to work this way you'll probably need to unmount the remote share before your Retrospect Script is scheduled to run; that's assuming you Added the Source to Retrospect before/without mounting it as another user, so the path Retrospect stores is what you want (/Volumes/Foo/); reference the Path field of the Overview section of the Summary tab of the Sources window to see what Retrospect will be using, and compare that if necessary against what you see from a 'mount' command in Terminal.

 

 

So I unmounted the shares and once again attempted to add them as shares, this time unmounted. At all other times I had added them when they were already mounted on the server/workstation. I received back error message telling me "path not found" when using the name of the NAS in the address (smb://nas-hd1/(share name). I have tried repeatedly, with same result. I then attempted to add the shares using the IP address for the NAS and succeeded in adding the shares as sources (smb://192.168.../(share name)). Now what I want to know, and I guess I will soon discover, is this new address for the exact same shares (using the IP address) going to be treated differently by Retrospect, as if not mounted, since I mount the shares using the NAS device name (nas-hd1). What do you expect to happen?

[f30e6e60-a263-4d69-8f60-c92703669308]

What do you expect to happen?

 

I have no expectations, as I lack sufficient knowledge to theorize. I don't know how your DNS is configured, I don't know if you've restarted the engine host machine before attempting to reconfigure your Source, I don't know what is shown by "mount" via Terminal.

 

Still, the results you get from your tests may prove valuable, but are nevertheless sure to be inconclusive.

 

 

Dave

[Guest Toolman1848]

I have no expectations, as I lack sufficient knowledge to theorize. I don't know how your DNS is configured, I don't know if you've restarted the engine host machine before attempting to reconfigure your Source, I don't know what is shown by "mount" via Terminal.

 

Still, the results you get from your tests may prove valuable, but are nevertheless sure to be inconclusive.

 

 

Dave

 

 

OK-Update: I removed all of the pertinent sources from the NAS device that were named with the NAS name (nas-hd1) and then added them back in but using the IP address for the NAS drive. As I said earlier, these shares are mounted on my sever/workstation since I use them for storing files that I share with my laptop. Amazingly to me, there shares are backing up without loss of connection. Same shares, just using the IP to add them instead of the NAS name which I use to mount them on my workstation.

 

I do not understand the logic of this from a programming standpoint--I am not a programmer--but if it works then I am happy.

 

Thanks for you help

[f30e6e60-a263-4d69-8f60-c92703669308]

I removed all of the pertinent sources from the NAS device that were named with the NAS name (nas-hd1) and then added them back in but using the IP address for the NAS drive

 

I'm not entirely certain what your steps were, but the issues related to naming apply only to the file-sharing volume name, as seen in Mac OS X by the name in /Volumes/. The protocol or URL used to access the share really aren't involved.

 

It's grand that it's working for you now, but that could simply be a coincidence of your rebuilding steps. The Finder is quite forgiving/dynamic with this; if a volume gets renamed to avoid system confusion (Foo-1), Finder.app will _display_ the unmodified name (Foo) to make it easier for humans to deal. But Retrospect uses absolute paths to describe resources such as Media Set Members and Source volumes. They may play nice for you now, but depending on the restart/mount/unmount etc steps you take in the future a mismatch could again occur.

 

Note that this issue has been, from the very first working release of Retrospect 8, the most wildly problematic attribute of the software, at least judging by the number of users asking about it on the Forum.

 

The fact is, networked share-points used as Sources, either in the logical sense of "source" (the place where your data comes from) or as the twisted sense of "source" that the Retrospect 8 designers used ("even though it's really a destination where your Member is being stored, since it _could_ be used as a place where your data comes from we're just gonna call it the same name and treat it the same way") work best when they're used by the RetroEngine user only.

 

Of course you could enable the root password on your system and log in as System Administrator, which would avert the problem entirely. But that would not be a Good Idea for many other reasons.