Hi everyone, I’m getting emails like this after i updated to 1.7.6/1.7.7. The emails coming from two different servers running Debian 11.
Subject: Output from your job 1
Body: sh: 20: cd: can’t cd to /tmp/tmp.66gXSbxLdy
Execution directory inaccessible
The job number is changing in the title so it’s not a specific cronjob. It’s clearly a permissions issue but I can’t see the tmp.66gXSbxLdy directory in the root /tmp so it could be somewhere else?
Strange have no idea……
Start by checking the delivery time of the email that you’re getting. It should be around the same time every day. Then check what Cron jobs are running just before that time. That might help you start to narrow down the culprit.
Tnx cmstew!
The emails are coming randomly without any connection to what i see on the logs or the time the jobs are starting to run.
And nothing special found on the logs, Just the jobs running … 
May 23 06:00:01 host CRON[9838]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue backup)
May 23 06:00:01 host CRON[9839]: (root) CMD (/usr/local/maldetect/maldet --mkpubpaths >> /dev/null 2>&1)
May 23 06:00:01 host CRON[9840]: (admin) CMD (sudo /usr/local/hestia/bin/v-check-disk-band)
May 23 06:00:01 host CRON[9841]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-rrd)
May 23 06:00:01 host CRON[9843]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue restart)
May 23 06:02:01 host CRON[10328]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue restart)
May 23 06:04:01 host CRON[10433]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue restart)
I found another thread about this issue in the forum and there is no clear answer how to fix this. 
Since 1.7.6/1.7.7 I occasionally have the same error at night. I could not find the origin.
Today I debugged a let’s encrypt not renewing for one particular website. I manually run v-update-letsencrypt-ssl and manually restarted nginx.
Guess what? That same error in my mailbox at that time.
So it looks like it has something to dot with v-update-letsencrypt-ssl or the restart of nginx.
I confirm that there is such an error, and it does not depend on time, which aggravates the search for the cause of its occurrence. I don’t remember exactly when the hestia 1.7.7 update came out, but I’ve received two such messages so far. At what, as far as I understand, this cron job is executed every day, but I received errors only on May 20 and May 28, this is definitely related to cron v-update-letsenscript-ssl, since I have no other tasks close to this time period. I’ve tried stopping this job and restarting it several times and I didn’t get the error…
Thanks @Esmertec It’s probably related to the certificate renewal date of a specific domain name. The script is calling another scripts like “v-add-letsencrypt-domain“. somewhere on the road one of the scripts is using the command “cd /tmp…” we need to find the real path to see what is the permissions there.
I have a similar error sometimes appears and one more is connected with the NTP that I have not installed on Debian 11.
sh: 20: cd: can’t cd to /tmp/tmp.ZGJSCQ10BI
Execution directory inaccessible
/etc/cron.daily/ntpdate:
/etc/cron.daily/ntpdate: 2: /usr/sbin/ntpdate: not found
run-parts: /etc/cron.daily/ntpdate exited with return code 127
Is it necessary to install NTP, or is Systemd-Timesyncd enough?
Thanks @Denys I run the command “run-parts /etc/cron.daily“ and no error or email. When I looked the ntpdate file i see:
#!/bin/sh
MAILTO=“”
/sbin/ntpdate -s time.google.com
Why the ntpdate use the “cd /tmp….” ?
These are two different errors that are not related to each other. I have not installed NTP, but cron tried to launch it, so I asked: Is it necessary to install NTP, or is Systemd-Timesyncd enough?
Hi. I have the same problem. I have receive a mail for each cron marked by a red arrow:
Perhaps I had another mails and had delete it.
Is there a solution?
Regards.
I am experiencing the same problem, receiving identical error messages via email approximately every 5-10 days at around the same time (give or take a minute or two). The issue can be summarized as follows:
SUBJECT: Output from your job 43
BODY:
sh: 20: cd: can't cd to /tmp/tmp.tOxE9z8NBi
Execution directory inaccessible
Upon reviewing the cron tasks of the user “admin” (responsible for the Hestia Control Panel’s automatic management tasks, accessed with crontab -u admin -e ), I found only one task that runs once a day, approximately 15 minutes prior to the time when the error email is received:
sudo /usr/local/hestia/bin/v-update-letsencrypt-ssl
Based on my limited expertise, I believe that occasionally the Let’s Encrypt process encounters some issue, taking approximately 15 minutes to terminate the unsuccessful operation and send us an email notification. I am uncertain about the significance of this error, but I assume it is relatively minor, particularly considering that the script runs successfully on most days. 
Nevertheless, I believe there are here more knowledgeable individuals who can provide a more definitive opinion on this “minor issue.”