Register for the iXsystems Community to get an ad-free experience and exclusive discounts in our eBay Store.

Execute jexec with user uucp / or how to execute jail commands from UPS service

Western Digital Drives - The Preferred Drives of FreeNAS and TrueNAS CORE


Junior Member
Aug 25, 2019
Hello community,
I just bought a UPS (APC Back-UPS CS 350) which seems to work very fine to shutdown my FreeNAS server.

But: I want more ;)
I want to shutdown other critical devices in my network automatically too.
Unfortunately, the other devices are really heterogenous, so I couldn't use any standard mechanism like NUT.

What I did: I created a jail, installed python and started scripting.
The python scripts are now capable of shutting down several devices in my network, according to their needs (e.g. some via SSH, some via telnet...).

I added a shell script to my FreeNAS shell (I put it to /usr/local/bin/
The shell script consists of:
  • several jexec calls, that execute python scripts in my jail
  • the actual shutdown command for the FreeNAS

I set chmod 777 to the shell script, that all roles are able to execute the command.

When I execute the shell script as root, everything works fine.

At the end, I replaced the "shutdown -h now" command in the UPS service with this:

Result: Only the FreeNAS server shutdown worked, all other commands aren't executed!

I did some research and I think I found the problem:
The UPS related processes (upsd is probably the one who does the actual call to the shutdown command?) all belong to the user "uucp"!

So I checked:
su -m uucp -c 'jexec ioc-MW-FreeBSD-Jail01 python3 /home/jailuser/'

really results in jexec: jail_attach(1): Operation not permitted

This doesn't happen, when I execute that command as root.

I also tried chmod 777 for the command jexec. Still the same.

Problem is: I tried everything I could figure out by myself, but I can't get it running!

It seems that I can't put the user "uucp" to wheel, or at least, not effectively.
Is there a way to start the UPS processes as root and not with this uucp user?

pw group mod wheel -m uucp seems not to work
adding the uucp user in the FreeNAS web UI seems to be possible, but actually isn't! The change is not done...

I need some new ideas... please :)
Last edited:


Neophyte Sage
Aug 19, 2017
Don’t use jsexec, use iocage exec.
run the script as root in FreeNAS but have the jail execute the command as the desired user.
make the script in the jail executable for the desired user, do not make it universally executable.


Junior Member
Aug 25, 2019
Thanks for the hint, I wasn't even aware of the fact, that jail commands can be executed with this. Now I finally understand, what iocage is :) Problem is still: Yes, I can execute the command from FreeNAS as root. But I need to be able to execute the command as user "uucp", because with this privilige, the UPS service is running from where the actual call comes from.
So either I need to eleveate the uucp user to root rights, or I need to somehow be able to tell FreeNAS, that the UPS related services have to be started with root user.

Any Idea on that?

Here is the trace: As root, no problem (as with jexec), but with uucp user: "You need to have root privileges to run exec"... :-(

Darrin M

Feb 18, 2021
I realize this is a bit old but a similar issue stalled me for a number of hours... my hope is that others may find this useful.
There are essentially 3 sets of permissions that need to be dealt with to successfully set a cron job to run in a jail...

Here is the jail I setup to periodically scan SAMBA shares that are mounted by the jail during startup (note the JID number).

TrueNAS Jail 2.png

TrueNAS Jail_LI.jpg

Above is a cron job set to run a clamav scan daily on SAMBA share directories mounted in this particular jail (JID9)

1. Permissions are needed to traverse into and perform work in jails (in my experience this appears limited to root and perhaps the wheel group).
2. Permissions are needed in the jail to run the desired action/executable/script.
3. The desired action/executable/script needs the proper access to perform its intended function (elevation by user or group activation).
(In the above example root runs 'jexec' on jail 9 using the internal user 'operator' to run a recursive clamscan on anything in the 'mnt' subdirectory)

Hopefully this will save some head scratching and hair pulling for someone out there...