Disambiguation of the meaning of "nobody" as an owner of an objects in the manager

[yannK]

I saw several questions about the user "nobody", and would like to get a clear explanation of the meaning and implication.

• In the UI in the search manager, I see sometimes saved searches with the owner "nobody"
• In the disk on $SPLUNK_HOME/etc/users I do not see a "nobody" profile folder
• In the apps, under local.meta or defaut.meta, for those shared searches (from the UI), I do not see an ownership like "owner = nobody"
• If I have an user that left, and was deleted, should I change the ownership of the objects to "nobody" ?
• I tried to create an user "nobody" in my local splunk users, but the manager refused, as it's a reserved name.
• I am using LDAP/SAML, I saw errors in the splunkd.log authentication about the user "nobody" not being found.

Here are some of the answers I saw, but they are too specific:
https://answers.splunk.com/answers/200590/what-are-splunk-system-user-and-nobody.html
https://answers.splunk.com/answers/678324/issue-with-usernobody-with-ldap-authentication.html
https://answers.splunk.com/answers/425941/what-does-nobody-under-owner-column-signify-in-spl.html

[yannK]

Here is the official answer at the time of Splunk version 6.6 7.0, 7.1 and 7.2

The user "nobody" in the manager is a catch all name for all the objects that :

1. Have no owner ( like an object that is shipped in an app without owner defined in default.meta, or local.meta)
2. OR were shared in the app, but where the user was removed from your authentication system (user deleted from the local splunk users, or removed from LDAP/SAML)

Technically, there is no user "nobody" in Splunk. The manager will NEVER allow you to create one, and you should not create such a user in LDAP.

However this can be confusing because :

• In the UI, you will see that name in the manager for objects that have no owner.
  • and in the scheduler.log, you will see it for the scheduled searches that have no owner.

What happens If a scheduled search has no owner :

• If the search is shared in the app, and it has no owner, then it will execute, and the job will have the permissions of the user "splunk-system-user" that inherit the role form "splunk-system-role" (to have the highest concurrency limits). This is what you will see in the job inspector (while in the scheduler.log it will say user=nobody, and in the savedsearch manager, and the |rest it will say "owner : nobody" )
• If the search has an owner, but it was deleted from LDAP, then the scheduler will still have to check LDAP to verify it's role, and will fail, and decide to not run the search. This is what happens for "orphan" searches.

What not to do if you have orphan object (and scheduled searches, or scheduled views ...)

• do not create an user named "nobody", please
• do not edit the local.meta or default.meta to add a line "owner=nobody" for the shared objects. ( Beware some bad bad bad naughty apps did use that trick in the past. PLEASE DO NOT DO THAT.) Otherwise you will be unable to distinguish them from searches without an owner, they will not run well, and cause unnecessary LDAP authentications that can slow down the scheduler.

What to do if you have orphan searches:

• Delete them (in the private profiles, and in the apps if they are shared) if you do not want to overload your system
• Reassign them to an existing user if you really need them to run again see this guide : http://docs.splunk.com/Documentation/Splunk/latest/Knowledge/Resolveorphanedsearches
• Eventually, you could migrate them to an app folder, and remove the ownership, then they will run as the "splunk-system-user" (like other searches shipped in apps' defaults)

[yannK]

About the solution "Reassign them to an existing user if you really need them to run again"

This is a good option if you have scheduled searches that need to keep running. You create a specific user (like a service user), with appropriate role with capacity for search concurrency and capabilities. And have the critical searches run as this user.

Then if you have other objects (fields extractions, views, etc...), that other users need to access, you can share them (in the app, or globally).

PS : this is equivalent to removing the ownership (and keep the object shared by default in the app). (by editing the conf files and meta files on disk, not possible to do so from the UI).
The difference is that those app object without owner are scheduled searches, they will run as the splunk-system-user, that usually inherits from the role admin.