@jame1997  1. Everything that is exists on the canvas resides in heap and is persisted to the flow.json.gz file written to the NiFi conf directory (default).  With every change made within the NiFi UI, the current flow.json.gz if moved to an archive directory and new flow.json.gz is generated.  All Nodes in a NiFi cluster use the same flow.json.gz.  You don;t need to stop NiFi to make a copy of the flow.json.gz file.  The NiFi flow.json.gz will contain encrypted values for all sensitive properties entered in any component on the NiFi UI canvas. In order for a NiFi instance to load a flow.json.gz, it must be cnfigured with the same "nifi.senstive.props.key" password used by the NiFi where the flow.json originated.  So always a good idea to backup your NiFi's conf directory (especially the nifi.properties file).  Keep in mind that all nodes in the NiFi Cluster must have same sensitive props key password configured, so unless you lose your entire NiFi cluster, you can get the flow.json.gz an sensitive.props.key form any nodes still accessible. 2. I am not crystal clear on what "backup all the processes" means.  Are you referring to all the dataflows built on the NiFi canvas? Some components (processors, controller services, reporting tasks) may have dependencies on other things like local/cluster state, local files, etc.  So those items need to be taken into consideration with any backup planning.  Each node in a NiFi cluster has a local state directory which hold state for components that use local state (listFile for example).  For other components, cluster state is used (cluster state is written to Zookeeper and Zookeeper quorum maintains protection of that information).  State is always changing as your dataflow is running, so it is not something to easily backup specifically for local state that has not redundancy across NiFi nodes.    Please help our community thrive. 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

@Kiranq  This error shared: 2024-10-17 08:35:19,764 ERROR [Timer-Driven Process Thread-5] o.a.n.c.s.StandardControllerServiceNode StandardControllerServiceNode[service=CSVRecordLookupService[id=a8b84b00-b0ee-31c8-dbda-7e7e9795ba4b], name=CSVRecordLookupService, active=true] Encountering difficulty enabling. (Validation State is INVALID: ['CSV File' is invalid because CSV File is required, 'Lookup Key Column' is invalid because Lookup Key Column is required]). Will continue trying to enable. Indicates that NiFi is trying to enable a NiFi Controller services loaded from the flow.json.gz during startup, but cannot because it's configuration is invalid.  It is complaining about the configuration of the "CSV File" and "Lookup Key Column" properties. Have you tried starting your NiFi with the following setting in your nifi.properties file set to "false": nifi.flowcontroller.autoResumeState=false This will start NiFi and all components on the canvas will not be started during startup. Also if you NiFi is at the point it is trying to enable components on the canvas, Your NiFi is up and running. As far as the screenshot error, have you verified ownership and permissions on that directory path.  Permissions can be an issue if you started the NiFI service as different users at some point in time resulting in some files created on startup having different ownership.    Please help our community thrive. 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

@HenriqueAX  The NiFi nodes themselves require a few authorizations within NiFi registry in order to start version control of a process group in NiFi. The NiFi nodes must be authorized in NiFi-Registry with: 1. "Can proxy user requests" - Read, Write, and Delete 2. "Can manage buckets" - Read Within NiFi you have setup your "Registry Client" that looks like this: For secure (HTTPS) NiFi-Registry URL, when an SSL Context Service is not defined, the default keystore and truststore configured in the NiFi.properties file is used to authenticate with NiFi-Registry through a mutual TLS exchange.  1. Did you setup an SSL Context Service? 2. If so, what keystore and truststore did you configure in the service? 3. Does the truststore used in the nifi-registry.properties file contain the necessary public certificates to include the complete trustchain for your NiFi keystore ClientAuth certificates? From the log snippet shared, it looks like the mutual TLS exchange is not resulting in a trusted clientAuth certificate being passed in the exchange (commonly a trust chain issue). So NiFi-Registry then checks for token in connection which would not exist in a NiFi to NiFi-Registry connection.  So what ends up happening is the connection is established as anonymous (just like you as a user sees when accessing NiFi before clicking login button). 2024-10-17 17:39:54,289 DEBUG [NiFi Registry Web Server-15] o.a.n.r.w.s.a.IdentityFilter Attempting to extract user credentials using X509IdentityProvider 2024-10-17 17:39:54,290 DEBUG [NiFi Registry Web Server-15] o.a.n.r.w.s.a.x.X509CertificateExtractor No client certificate found in request. 2024-10-17 17:39:54,290 DEBUG [NiFi Registry Web Server-15] o.a.n.r.w.s.a.IdentityFilter Attempting to extract user credentials using JwtIdentityProvider 2024-10-17 17:39:54,290 DEBUG [NiFi Registry Web Server-15] o.a.n.r.s.a.BearerAuthIdentityProvider HTTP Bearer Auth credentials not present. Not attempting to extract credentials for authentication. 2024-10-17 17:39:54,290 DEBUG [NiFi Registry Web Server-15] o.a.n.r.w.s.a.AnonymousIdentityFilter Set SecurityContextHolder to anonymous SecurityContext So you most likely need to resolve your trust between NiFi and NiFi-Registry.   Typically both NiFi and NiFi-Registry would use the same truststore containing all intermediate and root certificate authorities in the trust chain for the keystore certificates used on both services. Please help our community thrive. 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

@vg27  Sounds like you may have gotten past your original issue after following the guidance I provided already?  You new questions don't seem directly related to the original query. ------- The invalid host header can be resolved by modifying the nifi.web.proxy.host property in the nifi.properties file:   nifi.web.proxy.host=20.61.182.212,20.61.182.212:9443   Or by including additional entry(s) in your certificates SAN list. --------- Questions: 1. How re you authenticating this user identity?   CN=PAVANBL   2. Have you modified your nif.properties file so that the managed-authorizer is being used?   nifi.security.user.authorizer=managed-authorizer   3. What method(s) or user authentication have you decided to use? Did you just create an clientAuth certificate that you loaded into your browser to authenticate your user or did you setup some other auth method like kerberos or ldap?   nifi.security.user.login.identity.provider= 4. When it comes to using an load balancer, if you are using any type of login provider to authenticate to your NiFi, you need to configure the load-balancer to use session affinity (a.k.a - Sticky sessions).  When you login into a NiFi node the user is issued a client side token and a corresponding server side token is stored on the node.  That client side user token is send in every request made after login.  The issued client token is ONLY valid for use with the NiFi node that issued it.  So session affinity setup in the load balancer is required to make sure that all subsequent request within that same session go to the same NiFi node. Please help our community thrive. 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

@Kiranq  @livsey  If you configure "nifi.web.https.host" with your actual Windows hostname or IP rather then using the loopback address (127.0.0.1), does your NiFi start? Any custom add-ons? Have you set NiFi to debug in logback to see if any additional logging shed some light here? Thanks, Matt ... View more

@vg27  A few issues I see with what has been shared: Issue 1: IPV4 addresses like 0.0.0.0 and 127.0.0.1 are special reserved network addresses.  0.0.0.0 is not going to be resolvable to any network host.  0.0.0.0 is typically used by server applications running on multi-homed networks.  Meaning the the server has multiple NIC cards that are connected.  For example: one NIC connected to a companies internal private network and another NIC on same server connected to a public network.  BY configuring the server with 0.0.0.0, the special addresses tells the server to listen and accept connection from all NICs.  From the browser you would still need to use a resolvable IP address for accessing that server via one of the NICs.   NiFi offers a specific configuration property if you want to define multiple network interfaces you want NiFi to listen for connections on. 127.0.0.1 is the loopback address (localhost), which if used in NiFi, means NiFi is only listening on that loopback address.   So you should be configuring your "nifi.web.https.host" property for the hostname of the server on which it is running.  This hostname would need to be resolvable and reachable by your browser.   -------------------------- Issue 2: You are setting up. NiFi cluster, but are still using the single-user providers for authentication and authorization: nifi.security.user.authorizer=single-user-authorizer nifi.security.user.login.identity.provider=single-user-provider These providers were created so that users could launch NiFi standalone instances out-of-the-box for ease of product evaluation.  These providers are not suitable for clustered NiFi setups or multi-users environments. The authorizers.xml you shared is incomplete and only shows a "file-user-group-provider".   The authorizers.xml is easiest to read from bottom of the file upward.  At the very bottom you will find the authorizer (for example: "single-user-authorizer" or "managed-authorizer").   Depending on type of authorizer, the authorizer may utilize one or more additional providers ("file-access-policy-provider", composite-user-group-provider, ldap-user-group-provider", "file-user-group-provider", etc...) already loaded further up in the authorizers.xml.  So while you may have configured the "file-user-group-provider" and the that provider executes on NiFi creating a users.xml file, the configured single-user-authorizer would never use it.   --------------------------- Issue 3: Did you generate your own NiFi keystores and truststore for your 2 NiFi nodes or are you using the NiFi auto-generated keystore and truststore?   I encourage you to manage your own certificates, keystores, and truststores in a production setup.  The certificates generated  automatically are self-signed and only contain very specific Subject Alternative names.  In a cluster setup, NiFi nodes act as both clients and servers since they communicate with one another.  And the owner of those self-signed certifcates is going to be "localhost". This means that all nodes will report as same identity "localhost", which is not good for security. ------------------------------- Issue 4: I see you are using the embedded zookeeper (ZK).  ZK requires quorum in order to be useable.  With only 2 nodes, you only have 2 ZK nodes which is not a quorum.  IF either one of the nodes becomes unreachable or goes down, you will not be able to access the one remaining node either since ZK has lost quorum.   Quorum consists of an odd number of ZK nodes (typically 3 or 5) depending on how much loss tolerance you want to have.   While embedded ZK makes things easy with setup, you'll want to have at least 3 NiFi nodes (this allows you to lose up to one node and still retain access to the NiFi UI of the other 2 nodes.  Of course using an external ZK is even better and the best production option as stopping/starting or loss of NiFi nodes has no impact on quorum. --------------------------------- These are the areas to address first. Please help our community thrive. 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

@Suayb I see no ERROR logging in anything you have shared. The snippet of the nifi-app.log you shared only shows that NiFi is still starting up. NiFi is not fully up and the UI is not accessible until you see the following lines output in the nifi-app.log: 2024-10-17 09:24:32,817 INFO [main] org.apache.nifi.web.server.JettyServer Started Server on https://<hostname>:8443/nifi 2024-10-17 09:24:32,818 INFO [main] org.apache.nifi.BootstrapListener Successfully initiated communication with Bootstrap 2024-10-17 09:24:32,819 INFO [main] org.apache.nifi.NiFi Started Application Controller in 11.878 seconds (11878131211 ns) Are you seeing above in your nifi-app.log? Are you seeing any ERROR lines in any of you logs? are you seeing any disk space issues? Thanks, Matt ... View more

@Suayb  NiFi- 2.x requires Java 21 The make sure your NiFi is starting with Java 21 and not another version of Java. You configure a specific java in the NiFi.bootstrap.conf file.  By default in that file java is set to "java=java" which uses system default java.  You could could change this to "java=<path to java 21 bin dir>/java" If above does not solve issue start reviewing the nifi-bootstrap.log, nifi-app.log, and nifi-request.log for any relevant details. Please help our community thrive. 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

@livsey  Can you share what Java and Java version you are using and how you have configured your Apache NiFi conf/nifi.properties file? I am most interested in the Web Properties section. Thank you, Matt ... View more

@vg27  From your shared nifi.properties file, I can see you are using SSO based user authentication and Mutual TLS (always enabled) based authentication. For user authorization, you using the managed-authorizer. So when you access the NiFi UI you are being redirected to your SSO login, correct? After successful authentication, you are able to access the NiFi UI; however, when you click on the global menu in upper right corner, the menu has the users and policies greyed out and not clickable? If it is greyed out, it means the currently authenticated user is not authorized to access those items. What is the user identity string displayed in upper right corner above logout?  This case sensitive user identity string is what needs to be properly authorized. Can you share your authorizers.xml file?  This file sets up your authorizer and various sub provider it depends on for establish necessary access policies for your initial admin user and nodes.  That initial admin user's  identity string would get the minimum needed admin policies granted against it.   That admin user could then access the NiFi UI and be able to add additional user identity strings and apply policies to those new user identity strings or groups strings. A very basic authorizers.xml would have in it: File-user-group-provider --> Responsible for creating initial user identity strings for your initial admin and your NiFi nodes.   This provider generates a users.xml file only if one does not already exists.  It will not edit and existing users.xml. Your user identity must match exactly (case sensitive) with what you see in the NiFi UI.  From within the NiFi UI additional users and groups can be added later which will be also added to the users.xml file. File-access-policy-provider --> This provider is responsible for creating the authorizations.xml file that contains the policies that have been assigned to user or group identity strings.  It will only generate an authorizations.xml file if one does not exist.  It will not edit an existing authorizations.xml. When seeding initial policies for nodes and initial admin it expects to find those user and node identity strings from the file-user-group-provider.  Any newly setup policies via the NiFi UI will get added to the authorizations.xml. managed-authorizer ---> This authorizer points at the file-access-policy-provider to load the current authorizations.   Please help our community thrive. 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