Having a problem with a new Truenas Scale setup. I keep getting this error when running multireport.
Using sendmail.py
Send Failed
Retrying in xxx seconds
Please assist
You are facing problem sending email with the sendemail script.
First thing: the test email function from the truenas GUI is working?
If yes, login to shell and cd into the multi report dataset, then use
python3 sendemail.py --test_mode
this should show more detail about the problem and generate a log file that you can share here to troubleshoot better.
You can also trigger a simple email like that
python3 sendemail.py --subject "test" --to_address "YOURADDRESS@EMAIL.COM" --mail_body_html "test email"
Let me know
Multi-Report will try to send the email, if the result comes back that the email could not be sent, the script will wait a few seconds (I think 120) and retry. It will do this a few times and then try every 10 minutes for 1 hour before giving up. The reason I do this is because sometimes the mail server is not reachable, yes it happens. So I retry it. I see this problem with my email once every several months, but I have never seen it last more than a few retries.
Follow what @oxyde has said, if you are able to send an email that way but Multi-Report still has an issue, let us know. And also let us know if this is the first time using this script. It helps us narrow down the problem, which is likely a setup issue.
Happy April Fools Day
This is hopefully the last update for Multi-Report v3.x and Drive-Selftest v1.x
This is mainly a bug fix that has been ongoing for the past 3 months of small little fixes that affected a few people, and most it did not affect.
I did change the method of how a driveās smartctl interface is selected, and I maintained fallback interfaces should they be needed for some customization. I hope this will allow for better, more complete data collection, and possibly better communications with USB drives, although USB drives can be unwilling to play. If you have a USB drive that is not playing nice, please email me separately and we can try to work on it, or we find out it just will not support the required smartctl commands.
For those only using Drive_Selftest, this is a worthwhile update, however if yours is working fine, why mess with it.
As always, I will maintain the previous versions on GitHub incase you want to roll back.
If you find something wrong, please let me know so I can fix it right away and include it in the next release. If this is a new issue, you may want to roll back to the previous version if it was running okay.
Unless there is a major issue, this completes this version and I will continue to work on the next major release version. This one will be optimized to read the drives significantly less, code that just executes faster. I have no idea when the next release will happen, it is taking me longer than expected as Iām trying to just write the code in the best way possible and a lot of post-testing.
What was not updated: Disk Layout. This is still an āEarly Adopterā version 
and more progress will occur in the next major release.
4 Likes
@joeschmuck Hi Joe. Just to let you know my system sent me the following email.
The command:
cd /mnt/pool4/scripts_milo && ./multi_report.sh
Produced the following output:
/mnt/pool4/scripts_milo/drive_selftest.sh: line 2175: syntax error near unexpected token `('
/mnt/pool4/scripts_milo/drive_selftest.sh: line 2175: ` echo ' Drives_Test_Period: Options are "Week" (Mon-Sun) or "Month" (days 1 - 28)''
@alleykat Can yo please tell me the version of TrueNAS this was and the version of Drive_Seltest and also try to repeat it from the CLI using ./drive_selftest.sh -h as this line resides in the Help section only. This will not run another test on your drives, however if this error happened, and it did for you, that means no SMART testing was performed on your system, it aborted the one script and returned to the main script. Iād ask you for a dump but that would not help me at all.
And if the problem returns, you can edit the line 2181 in the drive_seftest.sh script version 1.09 to: echo " Drives_Test_Period: Options are 'Week' (Mon-Sun) or 'Month' (days 1 - 28)" and reverse the single and double quotes. However if you look up 5 lines, you will see the same format, single quotes around double quotes. So Iām not sure what is happening.
If the problem does not return after trying to display the Help screen, run the script normally ./drive_selftest.sh and this will run any test you have scheduled. Hopefully the problem does not return.
Thank you.
@joeschmuck Thanks for the reply Joe. I have three Truenas machines running at this time. They are:
oscar 25.10.1 drive_selftest v1.09 NO email error 4-2-26
pepper 25.10.1 drive_selftest v1.09 email error 4-2-26
milo 25.10.2.1 drive_selftest v1.09 email error 4-2-26
All have the Hide Standard Error box un-checked in the cron job. All three of these machines run the cron job for multi_report every night. No error emails since the 2nd.
Just to be clear, you only had the one error and none since? If true, it could have been something caused by the update. How do you know it wasnāt a delayed April Fools joke from your computer 
It was not from me but I use to do that, I had a message that would pop up saying something like āErasing your files confirmed, 10% remainingā, but it was not true. I removed that as it may make someone do something like press the OFF NOW button, in a panic.
In your multi_report_config.txt file, open it with a proper text editor such as nano, vi, or notepad++ (on Windows), search for truenas_sendmail_support="No" and if it states anything else, change it to "No". While the script should automatically take care of this since you have TrueNAS 25.10.x, this will just ensure nothing fishy happens.
@joeschmuck Thanks for the feedback! Just two of my machines sent one email each on the 2nd and no new emails. truenas_sendmail_support is no on all three machines already. Iāll just keep an eye on it, thanks again.
1 Like
Hello @joeschmuck,
I installed the new Version of MultiReport and also of the drive self test scripts. But my external name drive /dev/sdb is still shown as SMART disabled.
How can I enable SMART for this drive?
Best regards,
Christian
This is the response to thread 986
Hello,
which rights needs a new created user to run the multi report script as cron job.
Now I am using root.
Best regards
Christian
smartctl needs to be run as root, so I guess this is the answer.
1 Like
Not just smartctl, quite a lot of commands need to be a privileged account. You can make a different privileged account but why, it is still privileged.
Version 3.30 has a small bug in the Zpool/ZFS Total Data Read/Written values. This has no effect on the scripts testing and monitoring the drives. I did not make a change to it intentionally, I should have a new version within 24 hours. I need to test the correction before I post it.
Thanks to those who notified me about the error.
Hi @joeschmuck
How can I achieve that my drive /dev/sdb is also checked in the daily run of the script?
it is not shown in the list of devices at the start of the Mail and in the disk layout itās still shown in gray colour.
Best tegards
Christian
That is a good question. If it is not listed then typically smartct canāt talk to it. Usb drives are frequent offenders
Arg, smartphones!
Anyway, if this is not a usb drive, if you run the script using ./multi_report.sh -dump email then your system will send me an email with the drive details. It will help me help you.
Adding to the root vs. non-root user conversation, one could update all privileged commands in the scripts (multi_report.sh and drive_selftest.sh, maybe others) to prepend sudo and then update the /etc/sudoers to explicitly allow all the commands needed (using wildcards where needed) for a new user you create to run Multi Report. It might well even actually work. But how likely is TrueNAS to overwrite that sudoers file on any given system update? I suspect very likely (as many system changes Iāve made before get undone on updates). So to fully automate this, youād need a system init script or root cron job to check for and patch the sudoers file.
The security concern is absolutely valid. Having a root-level script that can be configured to auto-update itself has historically been used as an attack vector (even very recently). But Joe has to weigh the likelihood of those concerns against his actual development/testing/troubleshooting time. In the meantime, what I do is not let it auto-update, then I manually inspect each update with a diff from archive, so I know what changes Iām pulling in (and I have a couple small patches for my system I have to reapply). Itās worked pretty well for me so far these past few months.
Thanks for the kind words and thought you put into it.
This is fantastic advice and actually the default when Multi-Report is installed.
That is more work than most would do but it is the safest thing to do and if you every have a question about the safety of the script, please contact me immediately.
I do ensure my scripts do not cause damage, even if they donāt calculate things perfectly at times (v3.31 coming soon) hence Iām the only person who can change anything on my GitHub account. If I die, someone can fork it if they desire. @oxyde is the only person who has partial access to my repository, only a specific section, the webpage stuff as Iām clueless when it comes to CSS. HTML was good 40 years ago, time has passed me by. So I am in total control, until GitHub gets hacked, but then my script is the least likely to get hit. Iām thinking some obscure dependencies that are installed by Linux update. Trojan Horse six months down the road, after all your backups have been compromised. Grim, I know.
Cheers
1 Like