Failed to open stream: Permission denied

[sebastienserre]

I've removed and will monitor few days .
Thanks

[sebastienserre]

Removed it and no emails are fetch.
What's strange is I'm checking the emails on the Sogo Webmail (on Cloudron) and the email is mark as read... but not available on Freescout

[nebulon]

Have you restarted the app after removing the cron job, just to make sure the permissions are all set correctly?

[sebastienserre]

The error gone thank you @nebulon

I now have an issue on mails which are not fetched
This is now like if Cron tasks were not correctly done. The email is mark as read but not available in Freescout.

• Setting unread an email
• Visiting the URL https://example.com/system/cron/04c3f0b4a3771c3d76a2fac9a70b71a7 is fetching the unread emails.

and the email is in Freescout but as per Freescout

Cron Commands

Make sure that you have the following line in your crontab:
* * * * * php /app/code/artisan schedule:run >> /dev/null 2>&1
Alternatively cron job can be executed by requesting the following URL every minute (this method is not recommended as some features may not work as expected, use it at your own risk):
https://example.com/system/cron/04c3f0b4a3771c3d76a2fac9a70b71a7 

So I really do not know what I have to do

[nebulon]

Though this is exactly what the cronjob from the package already does. Cloudron runs that every minute. So at max it should take 1 minute for freescout to catch up on the emails.

You can also trigger the cloudron's cron job in the top right menu, if you open a webterminal into the app. Just to see if this fetches the mails correctly.

[sebastienserre]

yes but without the external cron no emails are fetch.

[nebulon]

I feel there is something else happening here, since both are running the same command. Can you run the cron shipped via the package (via the webterminal) and see if it shows any errors? We use freescout for the Cloudron support ticket and no further cron schedule should be required. Do you see any errors at all (besides the permissions issues, which are to be expected if you run some parts as root and they update cache files, which is wrong in the first place)

[sebastienserre]

I think the CRON are OK.
I do not understand why, but it seems that emails on this mailboxe are marked as read. I can't find how because I've checked the settings and there are no rules to mark a mail as read.
I've stopped SOGo and installed Roundcube, the same
The address is not setup in Thunderbird but I've tried by closing it, and the email is also marked as read...
is there logs I can check to know who and when a mail is marked as read ?

This is how if 1 cron task (marking as read) works but then an error arises.
here's an alert received by Freescout:

[2026-01-13 07:52:06] Erreur lors de la récupération de l'e-mail {"error":"Error: connection failed - stream_socket_client(): Unable to connect to ssl:\/\/mail.txxx.com:993 (Connection refused); File: \/app\/code\/overrides\/webklex\/php-imap\/src\/Connection\/Protocols\/ImapProtocol.php (95)","mailbox":"Support Thxxxo"}
``

[nebulon]

Ok so the cron from the package, fetching new mails works and no more permissions errors? Just to have that out of the way.

Is ther maybe some sieve script for that mailbox which could interact with mail like marking them as read?

[sebastienserre]

Yes the original permissions error is gone.
I really do not remember to have added any script but my brain is going these days....
where should these scripts could be readable?
I will check if something is wrong there.

[nebulon]

So you can find the sieve scripts for each mailbox at /home/yellowtent/boxdata/mail/<mailbox>/sieve via SSH. Maybe check if you have any for that mailbox, just so we can rule that out.