From afa88c8646fd92305109a693eb4344c507ed1a31 Mon Sep 17 00:00:00 2001 From: librelad Date: Sat, 23 May 2026 12:48:40 +0100 Subject: [PATCH] fix(crontab): clear user crontab as root so stale-owned spool files heal On installs migrated from EasyDocker the spool file /var/spool/cron/crontabs/ 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 -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 Signed-off-by: librelad --- scripts/crontab/crontab_clear.sh | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/scripts/crontab/crontab_clear.sh b/scripts/crontab/crontab_clear.sh index a85d3d4..7579c99 100755 --- a/scripts/crontab/crontab_clear.sh +++ b/scripts/crontab/crontab_clear.sh @@ -1,8 +1,13 @@ #!/bin/bash # 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." } \ No newline at end of file