Knowledge Management

Bug: Unable to Reassign Knowledge Objects with colons in the name

Path Finder

Hi fellow Splunkers!

I am an admin for our Splunk Enterprise Environment and when we have users on any of the teams that we support leave their teams or leave the company we try to stay on top of reassigning the knowledge objects that they owned to a current member of that team. We do this from the UI because we run 2 clustered environments with 3 SH's each.We reassign these objects by navigating to Settings > All configurations > Reassign Knowledge Objects

I have come across an issue where I am unable to reassign field extractions with colons in their name.


  • wineventlog:security : EXTRACT-WindowsSecurityFields
  • source::/var/opt/jfrog/artifactory/logs/request.log : EXTRACT-Action

When I attempt to reassign these I get the following error:


Has anyone else run into this? Has anyone found a solution (other than reassigning these from the back end)? Any feedback is appreciated!

Labels (2)
0 Karma

Esteemed Legend

This is a known bug but when I opened a support case, splunk closed the case.

0 Karma

Path Finder

I had a similar thing happen. Mine was closed and I was told to post on Splunk Ideas.

Here's the post in case anyone wants to upvote it:

Seems based on one reply that is was supposedly "under investigation" but that was 2 years ago and still seems to be an issue in 9.0.4.

I'm the team member responsible for managing this type of thing for all of the teams who use our enterprise wide Splunk environment but do not have the access/permissions to use a lot of the solutions people are suggesting on this thread so it's still a bit frustrating that we have objects owned by users who left the company 4 years ago.

0 Karma

Path Finder

UPDATE: I have actually noticed that Data Models can't be reassigned either as they also don't show up here

0 Karma

Splunk Employee
Splunk Employee


This is not a Search, it's a fields extraction and we can not reassign fields extraction.

You'll have to delete the fields extraction instead of reassigning the knowledge objects.

0 Karma

Path Finder

That actually isn't true....

I can re-assign all other "non-search" objects from the "All configurations" page:

  • props-extract (except for source based or ones with sourcetypes with colons.... see examples below)
  • transforms-extract
  • views
  • transforms-lookup
  • macros
  • eventtypes
  • fvtags
  • fieldaliases
  • workflow-actions

The only thing missing completely is calculated fields which I cannot reassign from this UI which doesn't seem to make sense when we can reassign all other objects from the UI.

I can reassign all other extracted fields and field transformations from the UI. The only ones that I cannot reassign are the ones that are source-based or are sourcetype based with a colon in the sourcetype name.

Sourcetype example:

Sourcetype: wineventlog:taskscheduler
Name: WinEventLogTaskScheduler-EventCode103Message
Regex: Task Scheduler failed to launch action \"(?P<FailedAction>[^\"]+)\" in instance \"\{(?P<FailedInstance>[^\"]+)\}\" of task \"(?P<Task>[^\"]+)\"\. Additional Data\: Error Value\: (?P<ErrorValue>[^\.]+)\. 
Field Extraction Name: wineventlog:taskscheduler : EXTRACT-WinEventLogTaskScheduler-EventCode103Message
***Please note the colon in the sourcetype name

Source example:
***I don't have a good source example that I would be able to post on here but for a fake example:

Source: this/is/a/pretend/source.log
Name: Destination
Regex: ^\w+\s\d+\s\d{2}:\d{2}:\d{2}\s(?<dest>\S+)
Field Extraction Name: source::this/is/a/pretend/source.log : EXTRACT-Destination
***Note that splunk adds the "source::" before the source.... I think the colons may be conflicting

I don't know for sure that the colon is the issue since I don't know how Splunk does the reassignment behind the scenes but based on some extensive testing I've done in my own environment (running on 8.1.3) this seems to be a common denominator....

I do have a bug investigation open with support to look into this issue.

0 Karma

Path Finder

I've encountered this issue as well - any update on how to resolve it?

Tags (1)
0 Karma

Path Finder

The fix they recommended to me was to use the REST method. Our team does not want to use this since that is not ideal in a clustered environment. I can update this thread if anything comes from the bug investigation that was submitted.  Fingers crossed it gets updated in a future version because the UI method is so much more convenient 🤞

0 Karma

Path Finder

I used the REST method, and found that it worked even in a clustered environment (Search Heads and indexers).

Command used on a search head:
curl -k -u admin:<password> https://localhost:8089/servicesNS/<old  owner>/ING-SA-Search/data/props/extractions/<object>/acl -d 'owner=<new owner>' -d 'sharing=app'

Where object is the urlencoded version of the full field extraction name, e.g.
my:srctype : EXTRACT-SomethingInteresting

I found that this change was then replicated to the other search heads appropriately

0 Karma

Path Finder

Hi @jimmoriarty , we have the same issue and tried using your workaround, but it does not work:
<?xml version="1.0" encoding="UTF-8"?>
<msg type="ERROR">Action forbidden.</msg>
Do you have any hints?

0 Karma

New Member

Convert <object> in urlencoded version.

curl -k -u admin:<password> https://localhost:8089/servicesNS/<old  owner>/<Object App>/data/props/extractions/<object>/acl -d 'owner=<new owner>' -d 'sharing=app'

It will work

0 Karma
Get Updates on the Splunk Community!

.conf24 | Day 0

Hello Splunk Community! My name is Chris, and I'm based in Canberra, Australia's capital, and I travelled for ...

Enhance Security Visibility with Splunk Enterprise Security 7.1 through Threat ...

(view in My Videos)Struggling with alert fatigue, lack of context, and prioritization around security ...

Troubleshooting the OpenTelemetry Collector

  In this tech talk, you’ll learn how to troubleshoot the OpenTelemetry collector - from checking the ...