My first stop would be firewalls and NAT translations in the path between the devices. For instance, are you using docker?
If the Zebra server doesn’t support passive mode, then the data connection can only be established by the Zebra server talking back to Lucee on its IP address. Which means you can’t have nat in the mix, unless you have a firewall in the middle that can translate.
FTP session goes something like this:
I have a file for you! Hit me up on a.b.c.d port e
Lucee< No prob, hitting you up
So if, for instance, you have a docker container - Lucee is probably ACTUALLY running on 172.17.0.x… and docker magically NATs it to your machine address on the way out. But it’s probably not smart enough to find “Hit me up on a.b.c.d port e” and rewrite it. Since 172.17.0.x only exists on your docker host, it’s not a routable IP on your network… printer can’t talk to lucee. This is why the FTP protocol isn’t great. (and it’s really old and has these problems and SFTP is better but if you had other options, you’d probably use them)
Assuming that’s the problem…
You might be able to convince your host machine to fix that problem, depending on if this is a linux on linux problem or what - by inserting the appropriate conntracking modules and FTP rewrite modules, or
You can set your network namespace to match your host with the --net=host option when you run the container - it won’t be isolated anymore, but it’ll know what its ip address is.
It’s going to come down to how your environment is configured.
Even if you’re not using a container there could still be NAT involved.