Fcrontab user: "ERROR could not change euid to <value>: Operation not permitted"

Installing & Running IPFire
1

Hi!

I’m getting a surprising error when attempting to list the fcrontab of fcronuser when logged in as that user.

I’ve following the instructions at the wiki post below to set up an `fcronuser` who’ll have their own crontab.

I’m creating this user because I’d been adding lines to root’s fcrontab, but these get overwritten on an IPFire upgrade (as explained in the forum post Crontab entry deleted after upgrading IPFire from Core 188 to 198 ).

I’ve followed the instructions closely. (Note: I had created a user using the useradd command specified in the post, but then decided I wanted them to have their own home directory, so deleted the user with userdel and then added them again, this time specifying -m instead of -c /. All other args remained the same. I expect the new user to be able to reuse the eponymous group created the first time. I mention this, in case it matters.)

I then followed the rest of the instructions, creating the entry /etc/sudoers.d/fcronuser and adding the user to /etc/fcron.allow, and finally added an fcrontab file with the desired entries.

I then opened a shell as fcronuser with the intent to check their fcrontab and run the various commands as that user, in order to apply the minimum amount of sudo for the commands run under fcrontab as fcronuser to work.

As root:

[root@ipfire cron]# sudo -u fcronuser bash --login -i
bash-5.3$

This approach allows me to bypass the fact that the fcronuser has /bin/false as their login shell.

I am indeed who I think I am:

bash-5.3$ id
uid=999(fcronuser) gid=999(fcronuser) groups=999(fcronuser)

When I go to list the fcrontab entries from this new shell, though, I get the following error.

Here’s the complete transcript, from opening a bash shell as fcronuser and attempting to list their fcrontab:

[root@ipfire cron]# sudo -u fcronuser bash --login -i
bash-5.3$ fcrontab -l
2026-01-20 14:36:26 ERROR could not change euid to 104: Operation not permitted
2026-01-20 14:36:26 ERROR fcron child aborted: this does not affect the main fcron daemon, but this may prevent a job from being run or an email from being sent.

Double-checking everything (including the spelling of fcronuser!), I see the account has been correctly created:

bash-5.3$ grep fcronuser /etc/passwd
fcronuser:x:999:999:non root fcrontab user:/home/fcronuser:/bin/false

There’s a valid entry in /etc/sudoers.d/fcronuser:

bash-5.3$ sudo cat /etc/sudoers.d/fcronuser
## Allow fcronuser to use sudo without a password
fcronuser       ALL=(ALL) NOPASSWD:ALL

They’re in /etc/fcron.allow:

bash-5.3$ sudo cat /etc/fcron.allow 
root
fcronuser

Probably the problem is that their don’t own their own fcrontab file:

bash-5.3$ sudo ls -l /var/spool/cron/fcronuser.orig
-rw-r----- 1 cron cron 526 Jan 20 14:11 /var/spool/cron/fcronuser.orig
bash-5.3$ cat /var/spool/cron/fcronuser.orig
cat: /var/spool/cron/fcronuser.orig: Permission denied
bash-5.3$ sudo cat /var/spool/cron/fcronuser.orig
<file content displayed, but redacted for clarity>

Given the user can’t see their own fcrontab, even if I edit it as root to add the appropriate sudo invocations, I have no confidence it’s going to be executed successfully.

What do you recommend?

2

Interestingly adding fcronuser to the cron group doesn’t make any difference:

bash-5.3$ groups fcronuser
fcronuser : fcronuser cron
bash-5.3$ fcrontab -l
2026-01-20 15:17:51 ERROR could not change euid to 104: Operation not permitted
2026-01-20 15:17:51 ERROR fcron child aborted: this does not affect the main fcron daemon, but this may prevent a job from being run or an email from being sent.

…but they can edit the contents of /var/spool/cron/fcronuser.orig, so I guess that’s something.

bash-5.3$  ls -l /var/spool/cron/
total 20
-rw------- 1 root root  479 Jan 20 14:58 fcronuser
-rw-r----- 1 cron cron  546 Jan 20 15:06 fcronuser.orig
-rw------- 1 root root 5722 Jan 20 15:02 root
-rw------- 1 root cron 3690 Jan 20 15:02 root.orig
3

You are trying to do actions with different users and groups as in the linked documentation.

The error you are getting is saying that the effective uid of the command being run could not be changed to cron.
All the commands in that original note are intended to be run by root and permissions are a critical thing here. That can cause complications.

The simplest approach would be to follow the note exactly as a first step and then when you have it working like that then modify things one step at a time making sure that each step works.

When I originally put the above together it took me many attempts to get the sequence of permissions etc correct. I had lots of failures along the way to getting a working process.

4

Thank you for the prompt reply!

I did follow the instructions exactly, but user fcronuser’s fcrontab isn’t being executed.

Interestingly, fcrontab segfaults if I attempt to enable debug mode:

# fcrontab -d fcronuser
2026-01-26 22:33:04 DEBUG   fcronconf=/etc/fcron.conf
Segmentation fault         fcrontab -d fcronuser

root is able to list fcronuser’s fcrontab:

# fcrontab -u fcronuser -l
2026-01-26 22:12:00  INFO listing fcronuser's fcrontab
<content>

@bonnietwin, perhaps you’ve deleted the test environment you were using to set up this alternate account, but if it’s still available, would you mind comparing the ownership and permissions listed below with your environment, please?

# id fcronuser
uid=999(fcronuser) gid=999(fcronuser) groups=999(fcronuser),104(cron)

# ls -ltrh /var/spool/cron
total 20K
-rw------- 1 root      cron      3.7K Jan 20 15:02 root.orig
-rw-r----- 1 fcronuser fcronuser  546 Jan 20 15:21 fcronuser.orig
-rw------- 1 root      root      5.6K Jan 26 21:58 root
-rw------- 1 root      root       479 Jan 26 21:58 fcronuser

# ls -l /etc/sudoers.d/
total 12
-rw-r--r-- 1 root root  89 Jan 20 14:09 fcronuser
-rw-r----- 1 root root 180 Dec 18  2024 logwatch-mdadm
-rw-r----- 1 root root  90 Oct  5  2020 setup

# ls -l /etc/fcron.allow
-rw-r----- 1 root cron 15 Jan 20 14:09 /etc/fcron.allow

General shout-out to other readers of this forum: has anyone else followed the instructions at www.ipfire.org - fcron to set up an fcrontab user and used it successfully?

5

Try the logging or debug option as described in the IPFire documentation. That starts without any segmentation fault.
https://www.ipfire.org/docs/pkgs/fcron#troubleshooting

It was not a test environment. I have the alternative fcronuser fcrontab running on my production system so that I can control scripts that I want to use to collect data. It has been running without any problems for around 4 years.

# id fcronuser
uid=998(fcronuser) gid=998(fcronuser) groups=998(fcronuser)

I don’t have the cron group defined for fcronuser. Not required to make fcronuser function.

# ls -ltrh /var/spool/cron/
total 20K
-rw-r----- 1 cron cron  616 Jan 13  2025 fcronuser.orig
-rw------- 1 root cron 3.7K Jan 11 14:44 root.orig
-rw------- 1 root root 5.6K Feb 22 11:56 root
-rw------- 1 root root  731 Feb 22 11:56 fcronuser

The fcrontabs are the same.

# ls -l /etc/sudoers.d/
total 16
-rw-r----- 1 root root 315 Jan  6  2025 01-anotheruser
-rw-r----- 1 root root 348 Jan  6  2025 02-fcronuser
-rw-r----- 1 root root 180 Feb 20  2025 logwatch-mdadm
-rw-r----- 1 root root  90 Feb 20  2025 setup

You have read permissions for group for your fcronuser but I suspect that was combined with adding the cron group to fcronuser and then giving it read permission. It shouldn’t block anything and is not needed.

# ls -l /etc/fcron.allow 
-rw-r----- 1 root cron 19 Oct 30 16:28 /etc/fcron.allow

This is the same.

So all your ownerships and permissions are looking like they should be.

I suspect it will be that your scripts that you are trying to run don’t have the full path defined or are not being run as the right user or are a sudo’d compound command where sudo will only apply to the first part of the compound command but not the rest. If that last issue is the case the simplest fix is to put the compound command into a script and then execute the script with sudo. I have that with one of my scripts. That will then apply the sudo environment to the script and hence the whole of the compound command.

Turn on the logging by removing the -y in the initscript as mentioned in the Troubleshooting section I linked above and if that does not give enough clues then replace the -y with a -d, which will turn on debugging. Warning, you will gets loads of logs with this approach so only use while troubleshooting.