Dell EMC Unity Family: The system cannot create a snapshot for storage resource xxxxxx because another snapshot creation for the same storage resource is in progress. Error 600026 (User Correctable)

A scheduled snapshot fails when the system tries to create the snapshot at the same time asynchronous replication is occurring.  Asynchronous replication uses snapshots under the covers.

Asynchronous replication (which uses snapshots under the covers) is occurring when the system attempts to create a scheduled snapshot.  The scheduled snapshot fails.

We are looking for evidence that asynchronous replication, using the replication snapshots, was occurring at the same time the system  was attempting to take a scheduled snapshot.  From Unity logs you can verify this is the case by following the process below.

In this example the error message indicates this snapshot failed: UTC_2020-05-11_04:03:00_APM00000000000

In TRiiAGE_ECOM.txt or cemtracer_uemjobsvc.log search for the snapshot name.  One of the entries found will be similar to the one below, indicating a CLI ID for the filesystem the system was attempting to take a snapshot of.  In this case the CLI ID is "res_119".
12 May 2020 04:02:57  - [UemJobServiceProvider] INFO - {0:12687397:418048258}[12083|22986|e59ffb40][EMC_UEM_TransactionJobLeaf @ ../../../components/providers/osls/UemJobServices/src/EMC_UEM_TransactionJobLeaf.cpp:351] 6 Extended Info Key-Value Pairs: {"FriendlyID": "root/emc:EMC_UEM_ApplicationLeaf%InstanceID=res_119", "ID": "root/emc:EMC_UEM_ApplicationLeaf%InstanceID=res_119", "JobType": "job.snapshot.type", "Name": "root/emc:EMC_UEM_ApplicationLeaf%InstanceID=res_119", "SnapID": "UTC_2020-05-11_04:03:00_APM00000000000", "Initiator": "SYSTEM"}

In the file replicationSession.csv search for "res_119" in the column labeled "srcResourceId".  For that record, the filesystem name will be in the column labeled "srcObjName".  In this example the filesystem name is "FS01"  If your CLI ID does not appear in the "srcResourceId" column, then it is not being replicated and this KB does not apply.
Alternatively, if you have access to the live system, to can find the filesystem name using the "CLI ID" column on the FileSystems page or with the command: 
   uemcli /stor/prov/fs show

In the file uemcli_repv2_sessions.txt search for "res_119" to find a table similar to the one below:
      +++++++++++++++++++++++++++++++++++++++++++++++++++
      Source Resource OID = 0x280000444C (res_119)
      +++++++++++++++++++++++++++++++++++++++++++++++++++
      System Snapshot: 0x280000444D
      Snapshot name: 171798709324_APM00000000000_0000.ckpt000_61537441879644770.1_10
      System Snapshot: 0x280000444E
      Snapshot name: 171798709324_APM00000000000_0000.ckpt000_61537441879651878.2_10
      Auxiliary Volume: 0xA000045ED
      Private VU: 0xA000045EE (tag=171798709324_10)

In the TRiiAGE_SPlogs.txt search for the System Snapshot IDs, in this example 0x280000444D and 0x280000444E, to find entires like these that occur at the same time as the failed snapshot:
B       05/12/20 04:03:00.777 mlu               16d0008 [INFO] System: Request received to set properties for snapshot 171798709324_APM00000000000_0000.ckpt000_61537441879651878.2_10. Snapshot is a UFS64, OID is 0x280000444E.
B       05/12/20 04:03:06.644 mlu               16d0004 [INFO] System: Request received to attach snapshot 171798709324_APM00000000000_0000.ckpt000_61537441879651878.2_10. Snapshot is a UFS64, OID is 0x280000444E.

These entries provide evidence that asynchronous replication of FS01 occurred at the same time the system was attempting to create a snapshot of FS01 - around 05/12/20 04:03:00.

This is functioning as designed.  The customer can adjust the snapshot schedule and/or the replication RPOs to avoid collisions.  Collisions may be difficult to avoid if RPOs are short causing replications to occur frequently.  The scheduled snapshot may hit the replication window every now and then regardless of how they are adjusted.