The “V” in “VNothing” it something I’m fixing now, it means you don’t have Drive_Selftest on your system.
I would run ./multi_report.sh -update_selftest and make sure you have version 1.03.
Read the Multi-Report Quickstart User Guide and Drive_Selftest User Guide.
I am working on version 1.04 right now to fix the “VNothing” strange thing, fix a few small grammer issues, and adding some features.
Afaik this false mean that SMTP user and pass are not required… But i admit ATM the script doesn’t handle this specific use case.
I don’t think will require a lot of effort, if in the next hour/max tomorrow i will post you a different version of sendemail are you available to test It?
Yes I would be happy to test it. Thank you!
If that were possible without a lot of hassle it would be nice
I have placed a note in my next version to try to add this.
The sending criteria will be:
While adding a few checks is easy and fast, it is all the support code that makes it more than you would think. I have to update the -config, the -help, the User Guide, and test it to make sure it does what is expected, and I didn’t break anything.
However, I may send you an early version that is setup just with those settings and without all the other support built in. It will give you a chance to test drive it. May be tomorrow.
@joeschmuck What’s the reason you chose the have separate update switches? Would it not be easier to have -update check all additional scripts for updates?
here the modified version:
mr_sendemail.txt (21.8 KB)
replace the original mr_sendemail.py file in the multi report folder with this, you will need to change the extension from txt to py.
Please let me know the result, i think this should be enough but in case share eventually log generated from the script.
Thank you oxyde, I now receive the report email from both the shell command and cron with the updated mr_sendemail.py.
Saving Log (file name: /mnt/TwoTBPool/scripts/DS_Logs/drive_test_29.txt)
Exiting Joe's SMART Drive Self-test Script
Collecting Multi-Report Data...
Using mr_sendemail.py
Email Sent
All updated, all working, no problems with the script, email received:
Excellent work from Joe, oxyde, the community, thanks again!
That’s odd. Even after updating to the latest version of multi_report, mine doesn’t show the version number of drive_selftest.
root@truenas[/mnt/TrueNAS/scripts/multi_report]# ./multi_report.sh
Multi-Report v3.14 dtd:2025-01-28 (TrueNAS Scale 24.10.1)
Checking for Updates
1. Multi-Report - Installed: 3.14, GitHub: 3.14 - No Update
2. Drive_Selftest - Installed: , GitHub: 1.03 - No Update
3. Sendemail - Installed: 0.14, GitHub: 0.14 - No Update
Well it would be easier unless you only wanted to update a single component.
But if you wanted to update all three files, just use -update_all and your command will be done.
That is odd. I thought I fixed it in v3.14. If it is not installed, it should say “Not Installed”, if it is installed, it should tell you the version. Since it says “No Update”, I have to assume 1.03 is installed. Please let me know what you find out.
So I just check in the script file and it says it was version 1. 
Just ran -update_all and it allowed me to download the latest version of selftest.
Running the report now shows the version number. My bad.
Weird I never got a notice while running multi_report there was a new version for drive_selftest, or that it didn’t download an update.
As an aside for -update_all, it doesn’t allow you to skip an update. It start with multi_report and if you do anything other than allow it to download (even if you have the same version), it’ll abort and not check the other scripts for updates.
Maybe have the update command check for updates and ask for user input if they want to update any or all.
Thanks for that feedback, I will make a note to address it in the next version.
Just wanted to defend our honor here…
1st we love what @joeschmuck is doing. We build and run these forums for free to make this collaboration possible.
We do contribute… but at the middleware level. Joe recently had a sendmail issue and we helped him fix that. We are maintaining SMART tests etc.
For our Enterprises, we have various tools, but we focus on pro-active alerts. We have customers with 5,000+ drives … they don’t want to read a report each day on all of their drives. They want us to monitor and help them work out what is needed and when.
Our observation is that these scripts are never perfect for everyone… Some users have different concerns and want different reports. We’d prefer its easy for anyone to customize without us having to make it a feature in a new TrueNAS release.
For that reason, we also make reports available in TrueCommand. These can be customized and don’t depend on a specific TrueNAS version. TrueCommand is free to Community users with less than 50 drives.
So, do we do nothing? … that’s a bit unfair.
Do we do everything… no, We call it Community for a reason. If we did more, we’d have to charge for it to compensate our employees and then there would be more objections.
The more we sell Enterprise, the more Engineering benefits the Community gets.
I did not say that, and did not mean that.
It was a meant as a response to this.
I understand why you would not want to incorporate it into truenas, but felt there are other ways to help well short of that, like contributing bits of code in situation like this, where something on the truenas side breaks the script completely.
I did not know that, sounds interesting.
Thanks for the input 
It’s really helpful to understand the position of iX in relation to Enterprise. I work in a field almost entirely unrelated to technology (About the closest in healthcare I get is moaning about the work VPN and the electronic patient record system), so I’m pretty far removed from groking the current state of enterprise needs and how that trickles down to the community benefit.
I know I’ll be investigating TrueCommand when I get a chance now, as I didn’t realise this was a tool accessible by the community with customisable reports.
I really like the script, use it on production servers and have helped test (break) some recent changes to the script. I very much appreciate @joeschmuck and those in the community who have helped him in time given and programming effort get the email working @oxyde with the script and new requested reports added and updated docs.
I don’t think that the multi-report script should or even needs to be incorporated into Truenas and I don’t think iX wants to take it over to do so (for script security) which would be what would need to happen for incorporation. As multi_report has grown it now depends on several individual scripts to perform specific tasks all of which would need to be incorporated somehow which isn’t likely.
There is strong community use and support for the script so an idea would be to turn it into a docker app where I think the script and community would benefit the most and maintain the most comparability with Scale.
One thing I would suggest to (new) users of the script is to set Check_For_Updates="true"
and then set the auto updates to false:
Automatic_MR_Update=“false”
Automatic_Sendemail_Update=“false”
Automatic_Selftest_Update=“false”
This will create a notification in the email when updates are available and what script module(s) needs the update but will not perform the updates. This in general is a good idea as:
1.) you control when the update(s) happen which is good admin policy
2.) in case a script update breaks something, your install won’t be affected.
That is the default setup.
As for docker, i do plan to look into this and i think it would just be easier for all involved, if it works.
I didn’t remember if false was the actual default on all. Some people are inclined I think to set to true for auto update with a “the script can do it so I … or…” then possibly set themselves up for an issue.
I know we discussed the Docker thing and you have been thinking about it, but didn’t want to put you on the spot on the public forums and others may chime in with their thoughts on it.