Effective December 3, NetApp adopts Microsoft’s Business-to-Customer (B2C) identity management to simplify and provide secure access to NetApp resources.
For accounts that did not pre-register (prior to Dec 3), access to your NetApp data may take up to 1 hour as your legacy NSS ID is synchronized to the new B2C identity.
To learn more, read the FAQ and watch the video.
Need assistance? Complete this form and select “Registration Issue” as the Feedback Category.

ONTAP Discussions

QSM Error - cannot connect to source filer - but only for one relationship!


Hi Guys,


Need a little help here. I have a 3 QSM relationships setup between two filers (FAS2552 & FAS2240). They're both on ONTAP 8.2.2 7-Mode. Now I have this weird behaviour that I cannot understand. Two of the QSM relationships are updating fine. The third one fails with an error "cannot connect to source filer". Yet all three relationships are are configured between the same filers. Basically, my setup looks like this:


filerA:/vol/vol1/qtree1          filerB:/vol/vol1/qtree1

filerA:/vol/vol1/qtree2          filerB:/vol/vol1/qtree2

filerA:/vol/vol1/qtree3          filerB:/vol/vol1/qtree3


So, the first to update fine. The third one fails with the stated error. This doesn't make much sence, since filerB connects successfully to filerA for the first two relationships!


The filers are in different locations, on different subnets. I have checked all /etc/hosts entries on both filers they're fine (they each have the host entries for both filers). The options snapmirror.access entry is set to "*" on filerA. I can ping filerB from filerA and viceversa. I can also ping filerB's gateway from filerA and viceversa.  I cannot do VSM because there are other qtrees in vol1 which we do not need to replicate.


Anyone encounter anything like this before?



Ok, so I rebooted the controller and now the error's gone. Weird. Anyway, problem solved. Thanks for all the suggestions.

View solution in original post



Ok, so I rebooted the controller and now the error's gone. Weird. Anyway, problem solved. Thanks for all the suggestions.

View solution in original post


Is there any more information in the snapmirror log?


Unfortunately not. Only the indicated error.


Ok, quick question, your snapmirror.access entry is *?


What's your snapmirror.allow read on the source?


We generally leave snapmirror.access = legacy


and then fill out the source snapmirror.allow with host name


I do not have an option called "snapmirror.allow". Here's my snapmirror options on the source:


snapmirror.access *
snapmirror.checkip.enable off
snapmirror.cmode.suspend off
snapmirror.delayed_acks.enable on
snapmirror.enable on
snapmirror.log.enable on
snapmirror.vbn_log_enable off (value might be overwritten in takeover)
snapmirror.vfiler0.logging.enable on
snapmirror.volume.local_nwk_bypass.enable on
snapmirror.vsm.volread.smtape_enable on


I have this same setup on 5 other snapmirror source filers and have no issues. Again. The weird thing is that two relationships are working just fine from the same source!


Have you looked in the snapmirror log on both the source and destination filers? they tend to report different things. Also, the messages file could have some extra info that may point to the cause of the issue.

NetApp on Discord Image

We're on Discord, are you?

Live Chat, Watch Parties, and More!

Explore Banner

Meet Explore, NetApp’s digital sales platform

Engage digitally throughout the sales process, from product discovery to configuration, and handle all your post-purchase needs.

NetApp Insights to Action
I2A Banner