Webstar/LibrePortal
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(crontab): clear user crontab as root so stale-owned spool files heal

Browse Source 
On installs migrated from EasyDocker the spool file
/var/spool/cron/crontabs/<user> can be left owned by a defunct UID. The
sticky bit on the spool directory then blocks the current install user from
replacing it, so every `crontab -` write failed with
"rename: Operation not permitted" while the scripts still printed success.

crontabClear now removes the crontab as root (`crontab -u <user> -r`), which
bypasses the sticky bit and clears the stale file; the setup steps recreate
it owned by the install user, so the next crontab refresh self-heals.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Signed-off-by: librelad <librelad@digitalangels.vip>
This commit is contained in:
librelad 2026-05-23 12:48:40 +01:00
parent fa6483cf94
commit afa88c8646
1 changed files with 7 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
scripts/crontab/crontab_clear.sh
View File

@ -3,6 +3,11 @@
# Function to remove all crontab data # Function to remove all crontab data
crontabClear() crontabClear()
{ {
echo "" | sudo -u $sudo_user_name crontab - # Remove the install user's crontab as root so a stale spool file owned by
# a defunct UID is cleared too — e.g. after the EasyDocker -> LibrePortal
# user rename. The sticky bit on /var/spool/cron/crontabs otherwise stops
# the user replacing a file it doesn't own ("rename: Operation not
# permitted"); setup recreates the crontab as the user next.
sudo crontab -u "$sudo_user_name" -r 2>/dev/null
isSuccessful "All crontab data has been deleted." isSuccessful "All crontab data has been deleted."
} }