Member since
07-30-2019
3381
Posts
1616
Kudos Received
998
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 221 | 10-20-2025 06:29 AM | |
| 361 | 10-10-2025 08:03 AM | |
| 281 | 10-08-2025 10:52 AM | |
| 281 | 10-08-2025 10:36 AM | |
| 338 | 10-03-2025 06:04 AM |
10-03-2025
06:04 AM
@Frank168 It would be difficult to say what the issue is without being able to see your authorizers.xml file and nifi-registry.properties file. One common mistake I see individuals make is copying from their NiFi's authorizers.xml. While they structurally are the same, NiFi-Registry has different class names for each provider in the authorizers.xml. The next suggestion i often make is start by reading your authorizers.xml from the bottom up starting with the authorizer (I expect that will be the "managed-authorizer" for you). That managed-authorizer will reference another provider and that referenced provider will reference another provider and so on. What you are making sure is that there is a referenced path from the managed-authorizer to your ldap-user-group-provider and likely your user-group-provider as well. I have seen scenarios where the individual providers were all configured correctly; however, the authorizer was not actually using them because there was not referenced path to them. Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt
... View more
10-02-2025
07:44 AM
@blackboks All actions performed against secured NiFi require proper authentication and authorization. It appears you have successful authentication via. mutualTLS exchange, but you are missing the proper authorization needed for the rest-api endpoint you are trying to access. The shared nifi-user.log entry tells you which authorization policy is missing for the user that is needed for the request endpoint /nifi-api/flow/metrics/prometheus: "view the user interface" which authorizes a user to /flow NiFI resource. I don't know how your NIFi has been configured to for authorization, but the most common setup uses the managed-authorizer. From the NiFi UI you can access the global policies from the NIFi global menu in the upper right corner of UI. "Policies" will open a new UI, where you can select "view the user interface" fomr the drop down selection: Then you can click on the person icon to the right to authorize additional user identities. Your list of user will be different. What is important to note is NiFi user and group identities are case sensitive and must match exactly. So the exact user identity shown in the nifi-user.log is the one that needs to be added to the "view the user interface" policy. If this user is not in the list, you must first add that user identity and then you will be able to authorize it. This can be done if you are using the managed-authorizer with the file-user-group-provider. If so, you can access "Users" from the NiFi global menu to open the NiFi Users UI: From there you can use the "+" icon to the right to add a new user identity. Remember that user identity string must match exactly case sensitive with what is shown in nifi-user.log; otherwise, it will be treated asa different user. Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt
... View more
10-02-2025
05:10 AM
@Zainers Unfortunately I don't think there is enough information shared to make any suggestion here yet. Could you share your exact NiFi version and more details around what you are trying to accomplish? Can you share the jython script you are using to restart NiFi? When you say it does not work using the NiFi executor, What executor are you talking about? What NiFi processors are you using? How are they configured? Thank you, Matt
... View more
10-01-2025
07:02 AM
@gunlomboy NiFi Site-To-Site (S2S) protocol was not designed for the use case you are trying to achieve. The ability to provide a comma separated list of hostnames in the Remote Process Group (RPG) exists simply to provide fault tolerance. The RPG will attempt to use the first hostname provided to fetch the S2S detail about the NiFi cluster from that host. These S2S details will include all the detail about the target NiFi cluster (This is why the RPG still distributed across all nodes in target cluster when only one hostname is provided). The extra hostnames provide fault tolerance for example lets say the hostname you configured is down, the RPG will attempt the second host to fetch S2S details. The S2S details fetched from the contacted host will include things like hostnames of all nodes connected to cluster, RAW enabled status, Raw Port for each host, Secure enabled, individual target node workload, etc. site-to-site-protocol-sequence By setting up firewall rules, you are not changing the S2S details being refreshed regularly and the RPG will continue to build a distribution algorithm that includes all the target host nodes. This means very inefficient transfer of FlowFiles. You might consider redesigning your dataflows to utilize PostHTTP processor (one for each host in target NiFi cluster with failure routed to other PostHTTP). Then setup a ListenHTTP on your receiving NIFi cluster. The postHTTP processor can be configured to "Send as FlowFile" so the NiFi Cluster will still receive the FlowFile content and associated FlowFile attributes/metadata just like how RPG sends FlowFiles. In Front of your ListenHTTP processor you could put a DistributeLoad processor to distribute FlowFiles being sent to your different target nodes. The downside to a setup like this is if you add additional nodes in your zone1 or zone2 of the target NiFi Cluster, You'll need to update your dataflows to add more PostHTTP processors for those new target hosts. You also lose the benefit of the workload based FlowFile distribution build into the S2S protocol. That being said, there is no other options since you can't change the functionality of the S2S protocol. Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt
... View more
09-26-2025
06:24 AM
@ragshetty I shared the Apache Jira which documented the removal of the encrypt-config toolkit in Apache NiFi 2.x releases. There is no alternative solution offered directly in the Apache NiFi product. NIFI-13414 Thank you, Matt
... View more
09-26-2025
06:14 AM
@IgorSpryzhkov You have asked a new unrelated question in an older post which already has an accepted answer. You would get better traction/visibility in the community of you were to start a new community question instead. Thank you, Matt
... View more
09-26-2025
06:09 AM
1 Kudo
@AlokKumar Did the assistance/information provided in the response(s) to your community question in this thread assist you? Please take a moment to accept the answer that provided the assisting information. Thank you, Matt
... View more
09-26-2025
06:09 AM
@AlokKumar Did the assistance/information provided in the response(s) to your community question in this thread assist you? Please take a moment to accept the answer that provided the assisting information. Thank you, Matt
... View more
09-26-2025
06:08 AM
@AlokKumar Did the assistance/information provided in the response(s) to your community question in this thread assist you? Please take a moment to accept the answer that provided the assisting information. Thank you, Matt
... View more
09-26-2025
06:08 AM
@AlokKumar Did the assistance/information provided in the response(s) to your community question in this thread assist you? Please take a moment to accept the answer that provided the assisting information. Thank you, Matt
... View more