Hello!
I just attempted to import a email (“Bulk action” in e-mail module), and until the latest update it has worked flawlessly, but now it fails with the error message:
How the error message is generated: 1.) Select “E-mails” module in the meny and go there. 2.) Selected the message by ticking the box of the chosen e-mail in inbox. 3.) Click “Bulk action” 4.) Chose from the dropdown list “Import” 5.) Error message is delivered in the browser.
Current version of SuiteCRM:
A quick peek in Devtools will generate this information:
Is the required files missing after latest update to version 7.13.4 from 7.12.4 maybe as Devtools tells you that it has received 500 internal error and also a 404 error?
Anyone here that have an idea why this occurs in this version and how to fix this?
Resetting permissions is only necessary if you broke them. You only break them if you didn’t set them correctly in the first place. They don’t magically break, it’s always due to a deterministic condition, and it is avoidable.
I understand lots of people have this problem, it’s tricky, and there’s too many wrong advice out there on this subject. But it brings me pain to see this eternally perpetuated… sigh…
As i said i only did the SuiteCRM update and now got more errors with the Mail Module.
I have further Mail Errors:
Wed Aug 16 15:38:55 2023 [32418][e811dcec-b5fa-9bf4-b377-5b7fdd852df3][FATAL] An Imap error detected: “IMAP open error: Can not authenticate to IMAP server: The Auth_SASL package is required for DIGEST-MD5 authentication”
Wed Aug 16 15:38:55 2023 [32418][e811dcec-b5fa-9bf4-b377-5b7fdd852df3][FATAL] An Imap error detected: “IMAP open error | debug data”
Wed Aug 16 15:38:55 2023 [32418][e811dcec-b5fa-9bf4-b377-5b7fdd852df3][FATAL] An Imap error detected: “ImapHandler:open: {imap.xxxx.de:993/service=imap/ssl/secure}INBOX”
Wed Aug 16 15:38:55 2023 [32418][e811dcec-b5fa-9bf4-b377-5b7fdd852df3][FATAL] An Imap error detected: “ImapHandler:open: info@xxxxx-xxxxx.de”
Wed Aug 16 15:38:55 2023 [32418][e811dcec-b5fa-9bf4-b377-5b7fdd852df3][FATAL] An Imap error detected: “ImapHandler:open: password is empty: no”
Wed Aug 16 15:38:55 2023 [32418][e811dcec-b5fa-9bf4-b377-5b7fdd852df3][FATAL] An Imap error detected: “ImapHandler:open: 32768”
Wed Aug 16 15:38:55 2023 [32418][e811dcec-b5fa-9bf4-b377-5b7fdd852df3][FATAL] An Imap error detected: "IMAP open error | debug data end "
Wed Aug 16 15:38:55 2023 [32418][e811dcec-b5fa-9bf4-b377-5b7fdd852df3][FATAL] ImapHandler trying to use a non valid resource stream.
Wed Aug 16 15:38:55 2023 [32418][e811dcec-b5fa-9bf4-b377-5b7fdd852df3][FATAL] An Imap error detected: “IMAP open error:Can not authenticate to IMAP server: The Auth_SASL package is required for DIGEST-MD5 authentication”
Wed Aug 16 15:38:55 2023 [32418][e811dcec-b5fa-9bf4-b377-5b7fdd852df3][FATAL] ImapHandler trying to use a non valid resource stream.
Wed Aug 16 15:38:55 2023 [32418][e811dcec-b5fa-9bf4-b377-5b7fdd852df3][FATAL] ImapHandler trying to use a non valid resource stream.
Wed Aug 16 15:38:55 2023 [32418][e811dcec-b5fa-9bf4-b377-5b7fdd852df3][FATAL] ImapHandler trying to use a non valid resource stream.
Wed Aug 16 15:38:55 2023 [32418][e811dcec-b5fa-9bf4-b377-5b7fdd852df3][FATAL] Couldn’t connect to mail server id: 6cd645cb-05d7-029b-e796-643a9ad361b0
I have not touched permissions at all.
The only thing we have done so far is running the upgrade process of the latest update to version 7.13.4 from 7.12.4…
So resetting permissions is out of the question then…(right?)
Thanks a bunch for alerting about this @pgr because we had planned to look into that on our server. So that probably saved us from breaking anything more/else (potentially), by tampering with file/folder permissions.
Still no idea though why this is going on or a way to fix it.
Is the update package 7.13.4 bugged or???
Permissions (or more precisely, in most cases, ownerships) get broken, usually, in one of 3 ways:
you login with a different user, edit files, or run composer, or something, and ownerships change so that your web server user can no longer read and write the files.
your crontab runs with a different user, makes some changes in the file system and caches, and ownerships change so that your web server user can no longer read and write the files.
SuiteCRM itself writes files and uses your config.php default_permissions settings, which are misconfigured, and breaks stuff
a bug in SuiteCRM when writing files. I know people will think “that’s the one I’m probably getting!”, but no, this is not something I would currently consider a likely event
I’m not saying you shouldn’t reset permissions - if they’re broken, then by all means, fix them. I am just saying that if your permissions keep needing to be re-set, you have something else you should be fixing first
Thanks @pgr
Not sure if they are broken. I mean everything worked up to this point when we updated and we haven’t changed anything ourselves. something happened after SuiteCRM was updated.
Is there a way to check if permissions have changed / is appropriate by the way for the system, (e.g. SuiteCRM)?
I suspect the answer is “no” and you have to check manually, right?
I forgot to mention that we do also have a separate test instance of SuiteCRM running on our server and it is suffering from the exactly the same error as our live production system. It also worked fine prior to the update.
So on our test system/test instance of SuiteCRM:
I tried and tested with requesting the page “emails” in the crm menu and then chose “Bulk Action” >>> Ticked the box of a email >>> “import” and then checked the server logs. It produced this result:
So here is the results produced in php_errors.log when attempting to access the email bulk import function in both the test system and the live production system:
I can see in that log entries mentioning issues with both connecting to SMTP and Imap. Never had these issues before or prior to this update 7.12.4. Everything worked flawlessly.
This update has really destroyed my system. Its the update from hell. I no longer can email from the production system:
This is also confirmed when you attempt so send a test email:
And we have done nothing of changes on this CRM instance.
We only ran the upgrade 7.12.4. and then hell broke lose.
Your email errors are telling me you cannot connect to your IMAP server. Check your credentials and see if you can do a connection test.
Also there’s this:
Also I’ve found the “ssl” dropdown, while does save, does not repopulate when you re-save. So you have to make sure it’s entered every time before you re-save.
Hi.
Already done that the outcome is this when sending test email which does confirm your theory about email accounts:
250-AUTH LOGIN
250-SIZE 40960000
250-HELP
250-AUTH=LOGIN
250 CLIENTID
1: CLIENT -> SERVER: AUTH LOGIN
2: SERVER -> CLIENT: 334 VXNlcm5hbWU6
1: CLIENT -> SERVER: ---obfuscated---
2: SERVER -> CLIENT: 334 UGFzc3dvcmQ6
1: CLIENT -> SERVER: ---obfuscated---
2: SERVER -> CLIENT: 535 Invalid Username or Password
1: SMTP ERROR: Password command failed: 535 Invalid Username or Password
3: SMTP Error: Could not authenticate.
1: CLIENT -> SERVER: QUIT
2: SERVER -> CLIENT: 221 Service closing transmission channel
However all email accounts where working before the update/upgrade to 7.12.4.
It doesn’t make any sense at all the ALL email account’s passwords has been automatically changed or wiped out of the database.
I changed the password / added it back on one account so far, and it did work it seems.
Still the email bulk import function is failing and I looked in every server log so far I could find (Apache, php, Plesk etc.), not to no avail.
It’s not actually set to none. In the DB it actually is “ssl” but if you look on the front end, it always says “none”. If you happen to re-save without changing to “ssl” it will in fact change it back to none. It’s a bug, you just have to remember to change it to SSL each time you save.
Hy stevens, SuiteCRM still have no Connection to the IMAP Server for Inbound E-Mails.
I changed the SSL and saved again but i got no connection after the update. It only says loading after i have clicked “Test connection”
It happens after the Update - i does not change anything else.
Gif video below is from our test CRM system instance. Same issue is replicated in live production environment too.
Well the issue still exists. Reviewing the server and PHP logs etc. has not really helped in finding the culprit of this issue. Everything worked fine until this update/upgrade to 7.12.4. where this issue stems from.
Any idea/suggestion that might lead to fixing this issue is very appreciated.
