[Broker Migration to UM] BRN.118.1022 - Broker Storage Read Error - Permission is denied

Hi ,

Following the 10.1 Broker to UM migration guide, trying to do jndi and jms migration. Both Source Broker and Target Um are running. On running the script with required parameters, getting the below error. Note that that Broke and UM is installed on same host with same root user. Script is executed with same root user.

Kindly suggest if any ACl’s have to be setup on Broker or authentication parameters to be passed in the command.

Comamnd used is:-
./brokerjndimigration.sh -brokerjndiurl “wmjmsnaming://Broker #1@XXXXX:YYYY” -targetjndiurl “nsp://XXXXX:YYYY”

Error - Exception in thread “main” javax.naming.CommunicationException: [BRN.118.1022] Broker Storage Read Error: Unable to load context WmJmsNamingContext from: Broker::JmsNaming::WmJmsNamingContext. Broker Exception: Cannot create or reconnect to client on Broker ‘Broker #1’ on host ‘XXXXX:YYYY’. Permission is denied. [Root exception is No Permission (109-1370): Cannot create or reconnect to client on Broker ‘Broker #1’ on host ‘localhost:2199’. Permission is denied.

You can check the help (./brokerjndimigration.sh -help) or the guide/readme for the tool, and see how to pass identification inputs. As far as I remember, these migration utility do not support identification (SSL or Basic Auth). So, easier will be to disable the authentication on Broker. You may need to disable user/authenticator ACL on admin client group in your JNDI Broker.

Thanks Sandeep. Yes script file don’t expect any authentication parameters as per help. I will try disabling the authentication to check this. but wondering how will migration happen in production ? as per guide source broker must be running and in production we can’t disable authentication when assets are UP . any thoughts around it.

Rohit,
You will be running JNDI migration utility way before actual production migration date. So, you can take a short migration window in production for temporarily disabling the ACLs and run migration utility. Other option is to use broker_save & broker_load (check -idhelp option) to replicate the production Broker in a test environment and then run migration utility on newly created Broker.
broker_save and broker_load handle not only actual Topic/Queues but also JNDI entries.