I set up a Raspberry Pi as a home server to run nightly backups of my family photos and documents to an external HDD. It’s been working flawlessly for months with a simple cron job that triggers a bash script at 2am. But starting last week, the backups just don’t run anymore. The script itself hasn’t changed, and there are no error logs or email notifications from cron. I’ve checked that the Pi is powered on and connected to the network each morning, and manually running the script works fine. I’m guessing something might have changed with the cron environment or permissions, but I haven’t touched any system configs. I also tried replacing the cron job with a systemd timer, but it behaves the same. Has anyone experienced this kind of silent failure with cron jobs on Raspberry Pi OS? What’s the best way to debug or log these kinds of background tasks that suddenly stop without any visible errors?

On 03/01/2026 at 2:40 AM, TechWhiz said:

I set up a Raspberry Pi as a home server to run nightly backups of my family photos and documents to an external HDD. It’s been working flawlessly for months with a simple cron job that triggers a bash script at 2am. But starting last week, the backups just don’t run anymore. The script itself hasn’t changed, and there are no error logs or email notifications from cron. I’ve checked that the Pi is powered on and connected to the network each morning, and manually running the script works fine. I’m guessing something might have changed with the cron environment or permissions, but I haven’t touched any system configs. I also tried replacing the cron job with a systemd timer, but it behaves the same. Has anyone experienced this kind of silent failure with cron jobs on Raspberry Pi OS? What’s the best way to debug or log these kinds of background tasks that suddenly stop without any visible errors?

Since manually running the script still works, it definitely sounds like an environment or permission issue with the cron context. One sneaky thing I ran into before was that the external HDD wasn’t always mounted at the time cron tried to run the backup, so the script silently failed. Double-check if the drive is mounted before the cron job runs, maybe add a mount check or a delay in the script.

Also, cron’s environment is super minimal, so if your script relies on any environment variables or paths, explicitly set those inside the script or source your profile. For logging, redirect both stdout and stderr to a file in the cron job line like */5 * * * * /path/to/script.sh >> /tmp/backup.log 2>&1 to catch any silent errors.

Since you tried systemd timers too with the same result, it might be worth adding some simple logging at

On 03/01/2026 at 2:40 AM, TechWhiz said:

I set up a Raspberry Pi as a home server to run nightly backups of my family photos and documents to an external HDD. It’s been working flawlessly for months with a simple cron job that triggers a bash script at 2am. But starting last week, the backups just don’t run anymore. The script itself hasn’t changed, and there are no error logs or email notifications from cron. I’ve checked that the Pi is powered on and connected to the network each morning, and manually running the script works fine. I’m guessing something might have changed with the cron environment or permissions, but I haven’t touched any system configs. I also tried replacing the cron job with a systemd timer, but it behaves the same. Has anyone experienced this kind of silent failure with cron jobs on Raspberry Pi OS? What’s the best way to debug or log these kinds of background tasks that suddenly stop without any visible errors?

It’s really odd that neither cron nor systemd timers are triggering your script anymore, especially with no error logs. Sometimes the Pi’s clock can get out of sync, which messes with scheduled tasks - have you checked if the system time is accurate after reboot? Also, external drives can sometimes fail to auto-mount after a reboot or power glitch, so your script might be running but not finding the HDD. Adding explicit mount checks or logging the mount status at the start of your script might shed some light.

Another thing I’ve learned the hard way: cron jobs often run with a very minimal environment, so if your script relies on any environment variables or relative paths, it might silently fail. Try adding full paths in your script and redirecting stdout and stderr to a log file to catch any hidden errors. Something like */1 * * * * /path/to/script.sh >> /home/pi/backup.log 2>&1 for

On 03/09/2026 at 7:45 PM, bp257 said:

On 03/01/2026 at 2:40 AM, TechWhiz said:

I set up a Raspberry Pi as a home server to run nightly backups of my family photos and documents to an external HDD. It’s been working flawlessly for months with a simple cron job that triggers a bash script at 2am. But starting last week, the backups just don’t run anymore. The script itself hasn’t changed, and there are no error logs or email notifications from cron. I’ve checked that the Pi is powered on and connected to the network each morning, and manually running the script works fine. I’m guessing something might have changed with the cron environment or permissions, but I haven’t touched any system configs. I also tried replacing the cron job with a systemd timer, but it behaves the same. Has anyone experienced this kind of silent failure with cron jobs on Raspberry Pi OS? What’s the best way to debug or log these kinds of background tasks that suddenly stop without any visible errors?

It’s really odd that neither cron nor systemd timers are triggering your script anymore, especially with no error logs. Sometimes the Pi’s clock can get out of sync, which messes with scheduled tasks - have you checked if the system time is accurate after reboot? Also, external drives can sometimes fail to auto-mount after a reboot or power glitch, so your script might be running but not finding the HDD. Adding explicit mount checks or logging the mount status at the start of your script might shed some light.

Another thing I’ve learned the hard way: cron jobs often run with a very minimal environment, so if your script relies on any environment variables or relative paths, it might silently fail. Try adding full paths in your script and redirecting stdout and stderr to a log file to catch any hidden errors. Something like */1 * * * * /path/to/script.sh >> /home/pi/backup.log 2>&1 for

@bp257, you nailed a key point about the environment differences between manual runs and cron. Sometimes cron jobs fail silently because they don’t have the same PATH or environment variables as your user shell. I’d recommend explicitly setting all needed environment variables at the top of your bash script or inside the cron job itself. Also, redirect both stdout and stderr to a log file to catch any hidden errors, like this:

0 2 * * * /path/to/backup.sh > /home/pi/backup.log 2>&1

That way, you get a trace of what’s happening overnight. Since you said systemd timers behave the same, it’s almost certainly something environmental or a permissions hiccup with the external HDD mount. Double-check that the drive is mounted before the job runs and that the Pi isn’t going into any power-saving mode that could interrupt the script.

On 03/04/2026 at 4:45 AM, dd495 said:

On 03/01/2026 at 2:40 AM, TechWhiz said:

I set up a Raspberry Pi as a home server to run nightly backups of my family photos and documents to an external HDD. It’s been working flawlessly for months with a simple cron job that triggers a bash script at 2am. But starting last week, the backups just don’t run anymore. The script itself hasn’t changed, and there are no error logs or email notifications from cron. I’ve checked that the Pi is powered on and connected to the network each morning, and manually running the script works fine. I’m guessing something might have changed with the cron environment or permissions, but I haven’t touched any system configs. I also tried replacing the cron job with a systemd timer, but it behaves the same. Has anyone experienced this kind of silent failure with cron jobs on Raspberry Pi OS? What’s the best way to debug or log these kinds of background tasks that suddenly stop without any visible errors?

Since manually running the script still works, it definitely sounds like an environment or permission issue with the cron context. One sneaky thing I ran into before was that the external HDD wasn’t always mounted at the time cron tried to run the backup, so the script silently failed. Double-check if the drive is mounted before the cron job runs, maybe add a mount check or a delay in the script.

Also, cron’s environment is super minimal, so if your script relies on any environment variables or paths, explicitly set those inside the script or source your profile. For logging, redirect both stdout and stderr to a file in the cron job line like */5 * * * * /path/to/script.sh >> /tmp/backup.log 2>&1 to catch any silent errors.

Since you tried systemd timers too with the same result, it might be worth adding some simple logging at

It’s interesting that both cron and systemd timers stopped triggering the script, especially with no error output. Since manual runs work fine, I’d double-check if the external HDD is reliably mounted at the time the job runs. Sometimes auto-mounts can fail after reboots or power cycles, and the script might silently exit if it can’t find the destination.

Also, try redirecting stdout and stderr from your cron job or systemd service to a dedicated log file. For example, add something like > /home/pi/backup.log 2>&1 at the end of your cron line. That way you can catch any subtle errors or permission issues that don’t get emailed or logged elsewhere.

One more thing: have you checked if any recent OS updates changed user permissions or cron behavior? Sometimes a system update can alter environment variables or user privileges, causing background jobs to fail silently. Comparing the environment variables in your manual