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.

VMware Solutions Discussions

Any way to eliminate SRM 5.0 / SRA 2.0 error message regarding CIFS share?


We recently upgraded to vSphere 5.0 / vCenter 5.0 / SRM 5.0 / NetApp SRA 2.0, and we notice a persistent "Error" message on the Array Managers panel of SRM:

Device '/vol/XXX/YYY' cannot be matched to a remote peer device

This particular volume (/vol/XXX/YYY) is simply our main CIFS file share, which happens to be replicated to the other filer using SnapMirror.  To me, it seems like perhaps the NetApp SRA is getting confused by this non-NFS and non-iSCSI SnapMirror relationship, and therefore producing an erroneous error message inside SRM.  It shows up for both the primary site Array Manager as well as the DR site Array Manager.

Any way to eliminate this erroneous error message from SRM?



Just to add the below requirements for NetApp with NFS mounts;

1. The hostname referenced in snapmirror.conf must match the actual hostname. If it does not (as in our case where the hostname is uppercase and in snapmirror.conf its lowercase), then SRA will have a problem discovering the array device.

2. Ensure that snapmirror relationships are not in a transferring state. If there are, transfers need to complete to confirm that SRA is able to pair the devices

3. Remove unneeded export statements for RO snapmirror destinations. Having these export statements may cause issues when attempting a Recovery operation in that the destination hosts may not be able to mount the volume due to the existing export statements. It's best to remove these and to allow SRA to create them during the Recovery operation.


I have been thinking about this..... in SRM 4.0 if you had a VM with Raw Device Mappings, you needed to make sure that the RDMs were on the same controller as the VM.

We have a FAS3140 and have some RDMs on the different controller to the VM. So I think the error occurs if the volume contains a LUN for RDM to a VM on the different controller. I am not able to confirm this yet, but I am reorganising our storage so will see if this resolves it. Will be a month or two until I have an answer.



@ahitoperations: Check out TR-3671, Page 12 Figure 8. "Many to one" Snapmirror Replication is unsupported. Sucks. I know. We found out the hard way...


Did you get an answer to this? I have the same error but the system seems to work fine.



No, I have not found a solution to this error message.  But you are correct; it does not appear to negatively affect the functionality of DR testing in SRM.  It's just annoying to see the big read error messages on the filers in the SRM interface.  I am assuming this bug will be fixed in the next SRA release.


Have you tried excluding the CIFs vol in the SRA setup?


I tried editing the Array Managers by excluding the volume containing the CIFS share, and then restarted the SRM services on both sides, and the error persists.  I am wondering if I need to completely delete the array managers and start over.  I probably won't try this because everything is working fine except for the annoying error message, which is just cosmetic at this point.


That is a great idea.  Let me try that and get back to you.

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