Почему lchown () всегда терпит неудачу в группе в корневом процессе через xinetd?

У меня есть приложение C ++, которое вызывает сервер на другой машине через xinetd сервис под Linux Centos5 64 бит. Вызванный процесс вызывается как root, но я думаю, что это может быть root, который не обладает полными возможностями из-за того, что я наблюдаю в своем приложении.

В моем приложении, работающем с правами root через вызов inetd, я создаю новый файл и ссылку (каждый изначально пользователь root и группа root), а затем вызываю lchown() успешно на владельца, но всегда терпит неудачу в группе с EPERMS, Operation not permitted, Объединение пользователя и группы в один вызов lchown() терпит неудачу аналогично.

Код в моем приложении выглядит так:

::lchown("pathnameToFile", uid_t(500), static_cast<unsigned>(-1)); // This line works
::lchown("pathnameToFile", static_cast<unsigned>(-1), gid_t(500)); // This line fails
::lchown("LinkToPathname", uid_t(500), static_cast<unsigned>(-1)); // This line works
::lchown("LinkToPathname", static_cast<unsigned>(-1), gid_t(500)); // This line fails

Вновь созданные файлы находятся в смонтированном каталоге NFS с такими правами после запуска моего кода:

drwxrwxr-x   2 me me   4096 Jun 22 17:33 .
drwxrwxrwx   2 me me   4096 Jun 22 17:33 ..
-rw-rw-r--   1 me root   33 Jun 22 17:33 pathnameToFile
lrwxrwxrwx   1 me root    8 Jun 22 17:33 LinkToPathname -> pathnameToFile

Гид 500 — это основная группа для «я», другая группа — «колесо».

> groups
me wheel

Из командной строки могу сделать chgrp вошли как root группировать me без проблем.

Почему lchown () ведет себя по-разному, когда мое приложение вызывается через inetd? Обратите внимание, что то же приложение вызывается как root через ssh правильно устанавливает владельца группы файла. Почему root через ssh отличается от root через xinetd?