I’m trying to configure a RabbitMQ shovel to move messages from an older broker (RabbitMQ 3.6.1) to a newer one (RabbitMQ 3.6.6). However, when I initialize the shovel, I keep getting a termination error on the source server with the message:
Reason for termination ==
{{badmatch,{error,not_allowed}}, …
It seems to fail when attempting to establish the connection or channel, but I’ve already confirmed the following:
The destination server is reachable (verified via telnet).
The credentials (user/password) are correct.
The vhost and queue exist on the destination server.
The shovel is configured using queue names, not exchanges.
Since this is my first time working with RabbitMQ shovels, I’m wondering if I’m missing a permission, policy, or configuration step that’s causing the not_allowed error.
Has anyone run into this issue or know what typically causes this kind of failure during shovel setup?
Thanks in advance for any insight.
Been working with RabbitMQ for a few years now, and I’ve hit the dreaded not_allowed error more times than I’d like to admit.
In one instance, I was setting up a shovel and kept getting that not_allowed response. Turned out, the user on the destination broker didn’t have the right permissions for the vhost—even though everything looked fine on the surface.
What fixed it:
rabbitmqctl set_permissions -p /myvhost user ".*" ".*" ".*"
That gave full configure/write/read access. After updating that, the shovel kicked in without any errors. So if you’re seeing this, check user permissions first, especially on custom or recently created vhosts. It’s the most common tripwire for this error.
Totally agree with @yanisleidi-rodriguez I’ve run into the same not_allowed issue, and once it wasn’t about permissions but about broker versions.”*
In my case, I was bridging a 3.6.1 source to a 3.6.6 target. The shovel config was using features not recognized by the older broker—like queue-length strategy and no_ack. RabbitMQ didn’t throw a descriptive error, just a not_allowed.
Here’s what helped:
Simplify the shovel definition, stick to basics first.
Ensure both sides have the shovel plugins enabled:
rabbitmq-plugins enable rabbitmq_shovel rabbitmq_shovel_management
After trimming down the config and restarting the shovel, everything synced without triggering the not_allowed again. If permissions check out, version mismatches and unsupported params are your next suspects.
Jumping in here, working mostly on RabbitMQ security and operations, and yup, the not_allowed can be sneakier than it looks.
Even with permissions and versions correct, internal policies can block shovel actions. In our case, some mirroring policies and federations were preventing queues from being accessed or bindings from being created dynamically. The shovel failed silently, only showing the not_allowed error.
What helped us was:
- Reviewing policies applied to the destination vhost.
- Verifying the user had rights beyond basic read/write, like policy exemption.
- Double-checking how queues were referenced in the config—shovel fails if the queue isn’t named exactly right.
So if you’re still stuck, look beyond config and permissions, RabbitMQ’s internal policies often block shovels without much explanation. Once we cleaned those up, the shovel connected fine across mixed versions.