@lafi_oussama  Have you tried upgrading to the latest version of Apache NiFi? You have not shared the specific ERROR you are encountering with the UnpackContent processor. You have not shared specific around what you tried using the ExecuteStreamCommand and Python scripts.  Any additional details you can provide about your zip files? Thanks, Matt ... View more

@Kiranq  The NiFi rest-api endpoint for obtaining token is not rest-api/access. It is rest-api/access/token https://<nifi-hostname>:<nifi-port>/nifi-api/access/token  and data passed like: --data-raw 'username=<username>&password=<user password>' Then the token needs to be passed with every subsequent rest-api request. If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@Sivagopal  What version of Apache NiFi are you using? There are some bugs that could lead to this. I recommend you are using Apache NiFi version 1.21 or newer. Is it always the same node that is disconnecting or appear random? Was the ERROR in the nifi-app.log followed by a full stack trace? - Make sure all nodes in your NiFi cluster are running with the same version of Apache NiFi. - Make sure that any custom or add-on nars and jars where added to all every node and have proper ownership and permissions. - Make sure all nodes use the same configured sensitive.props key and algorithm. Depending on your version of Apache NiFi, you may have a flow.xml.gz or both a flow.xml.gz and flow.json.gz files.  On the node that is disconnecting, stop the node, and then rename the existing flow.xml.gz and flow.json.gz (if exists).  If you restart NiFi, it will inherit the flow from the cluster when it joins and write new flow.xml.gz and flow.json.gz files to disk. If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@pacman  NiFi has never supported security zones.  There is no concept of zones in NiFi.  NiFi's established policies are extremely granular all the way to the individual low level components (processors, controller services, etc) level.  You have that level of individual user and group control within NiFi.   NiFi also does not support "deny" ranger policies.  A user is denied all except what they are authorized for directly or through inheritance. As far as to why /flow was working within a security zone... I have no idea.  Would need to see that downloaded policy json and maybe I could figure out why??? Glad I was able to help you get going with your Ranger integration with NiFi. Matt ... View more

Hello @pacman  Thank s for sharing your authorizers.xml configuration. While you have both the file-user-group-provider and file-access-policy-provider configured in your authorizers.xml, your configured Ranger-provider does not use them.  So these do nothing for you. When it comes to NiFi Resource Identifiers, they are very granular.   The /flow NiFi Resource Identifier simply grants the authorized user access to the UI.  It does not grant user ability to view (so you see no processor details or ability to open processor configuration to view it, modify, add, or delete any components.   This is why everything on the canvas is ghosted (All users will always see ghosted components, it helps prevent different teams from building dataflows on top of one another). NiFi does not fully support wildcard in all NiFi Resource Identifiers, "/*" should work, but I would not recommend it.  The intent here is to correctly and securely control these granular access controls.   When you access NiFi's UI, you land in the root Process Group (NiFi builds this root process group for you when NiFi is first launched).  Just like any other component a PG is assigned uuid.  With nothing selected you will see the root PG uuid displayed in the operate panel to the left side of the canvas.  Go ahead and copy that uuid.  Go over to the Ranger and create a new policy in your NiFi Ranger service.  In the NiFi Resource Identifier box paste that uuid.  You should then be presented with available NiFi Resource Identifiers associated that PG. NiFi components inherit permissions from PGs.  If grant user against a policy on that PG, all components created within that PG will inherit that same level of permissions unless you explicitly set a different policy on the sub component(s) or child process group(s). So if you give grant your user READ and Write on "/process-groups/<root PG uuid>", your user will be able to view and modify this process groups configuration and configuration of all components within this PG. Granting your user READ and WRITE on "/data/process-groups/<root pg uuid>" with allow you user to view content of FlowFile passed through components within this PG. The NiFi /resources endpoint returns all the available policies even those that would not be applicable when Ranger is managing authorization.  So adding any authorizations related to NiFi Resource Identifiers that contain "policies" make no sense and are not necessary for example.    I created  community articles that maps the /NiFi Resource Identifiers used in Ranger to the NiFi user interface human readable policies you would have seen prior to switching to to Ranger as your authorizer (also describes what each grants the user). https://community.cloudera.com/t5/Community-Articles/NiFi-Ranger-based-policy-descriptions/ta-p/246586 https://community.hortonworks.com/articles/226382/nifi-restricted-components-policy-descriptions.html These should help you with your journey here. If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more