How to resolve file blob store path warnings when upgrading to Nexus Repository 3.29 or later

As referenced in the 'Bug Fixes' section of the Nexus Repository 3.29 release notes, additional validation has been added to the file blob store creation process to ensure the configured file path is unique and is not contained in a sub-directory of another blob store.

This change includes a system status check to inform users of any upgraded blob stores that violate this requirement. 

If you have upgraded to Nexus Repository 3.29 or later, and wish to determine if any of your existing file blob stores are in violation, please check the "File Blob Stores Path" system status (available from the Nexus UI -> Support -> Status page) for a message similar to the following:

A file blob store must have a unique path, and may not be contained in a sub directory of another blob store. Blob stores with violations: blobstore-a, blobstore-b, blobstore-c"

If you are seeing this message, then the following options are available to you:

1. Correct the issue by moving the offending blob store(s) from out of the existing sub-directory, to a new location in the filesystem. The complete steps for moving a file blob store to a new location are covered in the Relocating Blob Stores KB article.
2. Correct the issue by moving the contents of the associated repositories to another/new valid blob store. The option of moving the contents of a repository to a new blob store is only available to Nexus Repository 3 Pro users via the 'Change Repository Blob Store' task.
3. Leave the configuration as-is and continue using the existing blob stores.

Either option 1 or 2 is recommended:

• You should go with option 1 if you are a Nexus Repository 3 OSS user or if you have a large number of repositories being serviced by the violating blob stores.
• You should go with option 2 if you are a Nexus Repository 3 Pro user and only have a small number of repositories (< 5) being serviced by the violating blob stores.

Option 3 is not recommended, but the violating blob stores will continue to work as they are. A major caveat, however, is that if the parent/containing blob store is ever deleted, it will also delete the contained blob stores. This will cause the associated repositories to stop functioning.