SMB File Shares are Unstable

[RadicalDad]

First off let me state that this is not a problem with SFFS. This appears to be a Mac OS problem. Help from any Mac supergeeks is welcome.

I am using three SFFS profiles to back up various folders to the same share on a Synoolgy NAS. The share name and its credentials are specified identically in "Mount Network Volumes..." on the Job sheet using the format smb://server/share. The Mac OS converts the SMB name into a /volumes mount point. The problem is that the mount point names are not stable.

I have seen the following problems on two Macs we just bought:

Anywhere from one to over a dozen connected server icons show up on the desktop, all connected to the same share. There have also been times when NO connected server icon shows on the desktop.

Attempting to connect via the Connect to Server dialog (Command-K in Finder) should show the share as grayed out as it is already in use. This is not always the case. Attempting to use the share in this way will break SuperFlexible's link to the NAS, with sometimes disastrous results (SFFS attempts to or actually succeeds in deleting everything on the left side).

Likewise, in the Finder sidebar, the NAS shared resource doesn't always show up as connected (the disconnect button is not displayed). If you attempt to use the shared resource in this state, the Finder will happily connect again to the NAS share – and break SuperFlexible’s link to the NAS as above.

The /Volumes folder shows multiple instances of mount points for the same share They are named share, share-1, share-2 etc. I've seen up to 35 of them at once, though I don't think they are all connected at the same time. These seem to be detritus left in the /volumes folder that makes the instability worse.

Two days ago the mount points were so broken on one of the Macs that any attempt to use the NAS or disconnect the share resulted in a system hang. The only way out was a hard shutdown via the power button. No amount of cleaning out the /Volumes folder or deleting various .plist files helped. I finally gave up and made an appointment with Apple Care, letting the computer sit unused for a day. When I went to boot the machine this morning in anticipation of the call from Apple Care, it was all happy again about using its shares. How or why it finally decided to fix itself is a mystery to me.

The problem here is that the linkage between the mount point and the software using it is so easily broken that it becomes terribly unreliable. A little Google research reveals that this appears to be a known problem, but I haven't found a solution.

Is this newbie Mac user error? Are there work-arounds? Is this just the way OS-X works? (Wow, Macs really are so much better than PC's!)

Any help appreciated.
Thanks

P.S. The folks at Apple Care were anti-helpful. After talking to 5 different techs over the course of 90 minutes, I finally got a senior engineer who said that they knew nothing about this issue and could not help me. I think that is universal tech-support speak for "Yes, we know we have a problem here, but we won't acknowledge it." Yep, they're another useless tech support organization, just like all the rest. OK, not quite like all the rest. They're Apple, so they were polite about it and suggested I hire an outside consultant to investigate the problem. (Really, that isn't a joke.)

P.P.S The support on this forum for SuperFlexible is stellar. I’m impressed that problems get fixed so quickly. Other computer companies should take a hint.

[superflexible]

Hello,

I think that MacOS chooses a new mount point when it believes that the old one is in use or something like that. I have seen this happen occasionally but never to such an extent. How often do your jobs run? Can you make sure you haven't chosen the checkmark to disconnect the volume at the end of the profile runs?

There are various ways to mount an SMB share, and two of them are used by our software, depending on the situation. One is a Mac OS API function and the other one is an AppleScript. Maybe I can program something to ensure a constant mount point. I will check.

[RadicalDad]

All three of the syncs are real time syncs (RTS), but they don't need to be. RTS doesn't seem to incur any performance penalty for the monitoring, so I leave all three that way, even though two of the folders have low activity and don't change often. The Documents folder does change regularly, and if the OS is generating a new mount point every time SFFS asks to use the resource, that would account for the seeming differences in how many mount points I'm seeing at any given time.

I don't even know where the checkmark is to disconnect the volume, so unless its on by default, I've not checked it. These profiles were converted from PC profiles (export on the PC, import on the Mac) so if that ould have done something to hit this checkmark, I cannot say.

Added stability is always nice if I can get that by a change to SFFS. Thanks. Too bad you have to work around this.

[superflexible]

OK in real-time, the program will never try to unmount the volume. But I will need to look into it and make some tests.

[RadicalDad]

I've been pursuing this problem with Apple, since it doesn't seem to be unique to SFFS (seen mention of the same problem other places). They had some questions / suggestions I can't speak to, but perhaps this is something known to you.

1) Is there an issue when more than one profile (3 in my case) tries to access the same NAS share? Will SFFS attempt to mount the share more than once, or can it determine that the share is already mounted and use the existing share for the next profile? I note that sometimes I see multiple shares mounted (with "-1" suffixes) on the desktop and sometimes not. Confidence is not inspired by the fact that under the same conditions I'm getting differing results at boot - mostly just 1 share, often two shares, occasionally 3 shares. Is there a latency issue about the OS reporting what is mounted to SFFS?

2) With regard to #1, would a work-around be to mount different shares? Right now the 3 profiles work on different folders in the same share. I could make that 3 different shares. Not desirable, but OK as a work-around for now.

3) Apple also mentioned a possible cause being improper dismount of the share. I can't say how you are dismounting the shares at system shutdown. Does this point you anywhere useful?

Thanks

[RadicalDad]

FWIW, this morning I watched SFFS create a new "-xx" alias in /Volumes every time every time a profile needed to do a sync. There were 12 aliases in /Volumes before I shut it down. There were also two shared resource icons for the same resource on my desktop, both created by SFFS at boot, and a third which was created by me when I used that resource via the Finder sidebar. Given the instability I'm seeing with SMB shares, I have to believe that this is not acceptable behavior. Where does the problem lie?

[superflexible]

Hi,

I'm sorry I haven't looked at the code yet. I will do it today.

The intention is certainly that the program recognizes mounted volumes and uses the existing mount points. It does not create new mount points itself. Instead it asks MacOS to mount the volume. It's possible that I can work around this problem by changing the code sightly, but MacOS is at least partly to blame too.

Cheers,
Tobias

[RadicalDad]

Thanks Tobias.

I understand that MacOS isn't doing something desirable here. Thats why I asked about reporting latency or other OS issues where a request to work on an existing mount point turns into a request for a new mount point. Whether that problem occurs inside the OS without knowledge by SFFS, or occurs because the OS incorrectly reports its status so that SFFS then asks for a new mount point, either way its an OS issue. I also assume that you are using MacOS API tools for shares rather than creating such tools on your own. If you can't get the OS to behave, then the Macs get returned and we'll get Windows 7 machines. I don't have time to play with this. It just works in Windows, a funny thing to say about Windows relative to Mac if you believe the hype. (John Hodgman should give Justin Long a kick in the pants.)

I really appreciate all your effort.

--Bruce

[superflexible]

Hi,

concerning "improper dismounts": since you are using the real-time feature, there should never be any dismounts happening while the system is running. The "Disconnect" checkmark should be deselected in all the jobs. I'm sure it is. This is surely not the problem.

When you shutdown and restart, MacOS handles the dismounting and a restart is always clean anyway.

I think a possible cause might be if two jobs try to mount the volume exactly at the same time. That can happen if you use real-time sync and start the scheduler. I will make an update to prevent this from happening. Maybe that is the biggest part of the issue.

[superflexible]

I will also add an additional identification method for mounted volumes so that they are not re-mounted. Currently the program uses the standard MacOS volume enumeration method. But I have a feeling that it may sometimes miss a mounted volume. For example, I have seen volumes being mounted but not appearing on the desktop. Details to follow.