Can you run the following command:

server_df ALL

I'm wondering if the root fs('s) are busting at the seams.

In addition to possibly not having enough room on the VDM root fs for the secmap cache (in addition to being in memory it is also saved to file) or on the physical data mover's root fs not enough room for the usermapper files (unlikely but can be easily confirmed with the command noted above), I had 2 other random thoughts about usermapper in relation to GID requests.  To be honest though, when any of these situations occur, I'm not entirely certain if they would trigger the exact error message you received.

1) Maybe you have exceeded the (default) GID range of usermapper?

server_usermapper <physical dm> -Export -group group.umdb

cat group.umdb | wc -l

2) Is it possible that this array is configured with a secondary usermapper and the primary usermapper on a remote array is inaccessible?  A data mover that is assigned as a Primary usermapper is the only one that can create mappings for any new groups.

server_usermapper ALL

This is an apparent memory leak in usermapper. The error is referring to ENOMEM (memory). Restarting the service will stop the error from happening but not prevent it from re-occurring.

All volumes and root vdm volumes have plenty of capacity.

EAGAIN 11 /* No more processes */

ENOMEM 12 /* Not enough core */

EACCES 13 /* Permission denied */

I would suggest to open a service request and get customer service to diagnose

If you are not at the latest release you might want to upgrade – or at least look at the release notes if your problem is fixed in a newer release

SREQ opened at the same time I posted the thread. Support did not know what the root cause was but restarting it resolved the error. I believe this is a new issue to this release.

Version: T7.1.65.804