And that can easily be changed using the -config, new option “D”. When you use this, if there is better wording, please toss me a message. I’m too close to the project to always see through other eyes.
Oh how I wish that were true. It would have been better if there were no issues at all. Version 3.12 should be working. I have to fix a few things like the updates since it isn’t absolutely the way I wanted it to function, and you can see there is a lot of data on the CRON email, I want to remove a good portion of it, after we get some time on this version.
This is likely the issue. 24.10.1 really locked down what user accounts could and couldn’t do. Please read the Multi-Report Quick Start Guide. Run the script from CRON as either root or truenas_admin or a different privileged user. You should not need to use sudo. If you do get it working while using sudo, I wouldn’t mind if you reached out to me and told me how you did it. I’d like to capture that data, test it out myself, and then include it in the User Guides. It may work fine, I have not invested that much time into it.
Note The version 3.12 was updated this morning to reflect 19 January 2025. That is all that changed. If yours says 18 Jan, it should be fine. And if it is working, leave it alone. 3.13 will be out in the near future (7+ days unless there is a serious problem).
These are currently logged results not updated by a recent test.
You can compare power on time with the last test type (time conducted). If there’s a (large) difference between the two times, you’ll know it’s been a while since a test has been preformed.
I updated to 3.12. When I ran it from cron, first I got an email from cron that drive_selftest.sh was not found. The second time it downloaded again and found it. The execute flag is not set, but it doesn’t matter because I’m trying not to use it, using the TrueNAS GUI for smart tests.
Cron also complained that mr_sendemail.py could not be found. Indeed that doesn’t exist in the directory containing multi_report.sh, and I haven’t gotten any emails in a long time. Not sure what the problem is.
Ahh yes, I see it now: there’s a 16 hour difference between all of the times e.g. Short offline (24558 hrs) vs power on time 24574
A small difference which makes me think that test was performed recently - presumably yesterday when I was messing around. But not immediately before I did today’s update so I do need to look at the options. Thanks; I wouldn’t have spotted that detail.
If I choose option 3 in the multi_report.sh script, presumably ought I to delete these?
Personally I have multi_report ran daily doing a short test on all drives. Then I have long tests scheduled through the TrueNAS GUI.
The only ‘wrong’ thing to do is to never run smart tests. If you have tests scheduled through the gui, you don’t /need/ them scheduled through multi_report.
Edit: Also, choosing ‘3’ means the report doesn’t run tests. Removing the gui scheduled tests means no tests get run at all.
If I recall correctly (I may not) you were not getting the Text Section of the reports previously. Is that true? And now you are.
The default is to receive the Text Section. You can disable that in the config setup. But what you are seeing in Normal.
When using Multi-Report, you should only “need” to look at the email Subject line, if it says anything other than “Good”, then all that data is there to help identify the problem. It is a lot of data but it makes it easier to diagnose the issue.
And your normal email should say “Good”. If you have errors, send me a -dump email and in the message just ask me to give it a look. I typically respond fairly quickly. Sometimes a person has a few bad sectors and have not performed the automatic compensation adjustment.
No, not really. It gives you privileged access, but it is still fair to think that way. Odd, I’m not a Linux guru either but sudo su sounds odd. I’d have thought it would be sudo or su would be the same. sudo is Super User Do, su is Super User, basically the same thing I thought.
You are not the only one brother. I’m always learning.
You have Multi-Report running before this upgrade came out. Other than the script, what else changed? All the user commands should be the same if you were using TrueNAS 24.10.0.2 or earlier SCALE versions.
I just ran my CRON setup using truenas_admin vice root and all worked fine “except” I didn’t not get a copy of my TrueNAS configuration file because maybe I need to use sudo as well. But that comes with a possible can of worms, and I will investigate that tomorrow. But I was able to run the script and get an email. Also, on my system root is not the owner of my scripts, my user account is, so these files do not have to be owned by root.
So I just took a look at it. I had to make a small change to the truenas_admin account. Here is how (SCALE):
1.GUI → Credentials → Users → truenas_admin → Edit → scroll down → Allow All Sudo Command (check) → Allow all sudo commands without password (check) – Save.
2. In the CRON Job task, here is my command line, adjust yours accordingly:
cd /mnt/farm/scripts && sudo ./multi_report.sh
That is easy to figure out… In the big chart, look to the right for column Last Test Age. By default the alarm setpoint is 2 days (more precisely 48 hours) and if a test has occurred within the last 23:59 then the value will be “0”, between 24:00 and 47:59 it will be “1”, 28 hours or greater it will change color, tell you how many days (24 hour power on periods) it has not been tested, and the Subject line will tell you there is a Warning.
This is the main reason for having this script, to let you know for certain that your drives are being tested or not. A long time ago in a land far far away, if you replace a drive, or possibly just updated FreeNAS, the drives you had being tested would stop running. Many users did not find out until be problems with the drives started happening. And a script was born.
I still recommend a daily Short test and a Weekly Long test (depending on your drive test times.)
Run the script with the -update_sendemail option and then -update_selftest option. This will update the files. It is a known problem and I am resisting sending another update for a few days. I know of one other problem which I don’t believe is the script but I want to know for certain and if I need to fix it, just put out one more version change this week.
Sorry for all the confusion. It hasn’t been fun here either. If I had 5 more TrueNAS systems of varying hardware, maybe I could locate more incompatibilities. Donations? Kidding, I can’t afford that kind of electric bill.
Well, no, it’s really not an “all internet scripts have the same security risks” situation. Yours is much, much worse.
Perhaps you saw the results of the ZDI contest from November of last year. One of the hacks there was based on being able to trick TrueNAS CORE systems into executing arbitrary code as root, resulting in a remote compromise.
Having your script installed on a system re-introduces the same kind of vulnerability to both CORE and SCALE systems, except it’s easier to exploit.
To have any faith in their system’s security, people running your scripts have to:
Trust you (their choice)
Trust oxyde1989 (your choice)
Trust basilhendroff (your choice)
Trust that none of your choices have their github accounts compromised going forward (trusting your faith in their level of github competence). (Do I need to point out that basilhendroff’s github repo was last modified years before github started requiring 2FA?)
And those observations are based on a 10 minute examination of what your code is doing.
Given that your script runs both as root and periodically, the attacker gets multiple bites at the apple to hack EVERY TrueNAS system that your code is installed on. Simultaneously.
The fact that it has been wreck-less so far does not mean that you’re not being reckless.
iX Systems developers go to a great deal of trouble to avoid installing untrusted and untrustable code on their customers systems, and we still fail sometimes. You’re not even trying, and in fact, you’re deliberately installing untrusted code to run as root.
Adding to the list of security affronts: your script downloads compiled binaries of unknown provenance (gdisk, sgdisk) from your git repo. If you don’t know why that’s insanely terrible from a security point of view, you need to step back.
You don’t seem willing to shoulder the responsibility for the level of trust that you’re taking on.
I understand the need to make TrueNas as safe and secure as possible. No one wants to open their systems to potential problems. Joe has been involved with multi_report before XI systems, for better or worst, took the open source project over. Because of certain vulnerabilities I understand that sendmail was decommissioned and xi told Joe to use exim without any help whatsoever. Other members of the community stepped up to help fix the code that was now broken. You guys could have helped but chose not to. I understand your need to cater to enterprise customers… Oh, and btw I trust Joe as many do who have been running his script for years.
Now that you’ve started the ball rolling i would be really glad if you can point me to fix eventually critical issue regarding the send-email function i provided, for the sake of the community (and to lighten the load on Joe’s shoulders).
There was a long debacle in another thread, we tried to use the “built in” sendemail alternative with no success do to some limitations (the hard-to-make encoding, but most for the lenght of the payload). So, grabbing a tips, i tried to provide a functional wrapper for not let Joe to struggle more on this “stupid” problem (yes, IMHO, in 2025 send an email shouldn’t be so tricky).
I didn’t create anything new, i just get info from here and there and combine them for our scope, just most relevant
Also to mention: the script itself rely totally on mail.config provided in truenas, no sensible data is stored or saved or send; and offcourse, my github account is protected by 2FA.
That is sound advice. I always run short and long SMARTs (as per the TN webUI) and I was using multi_report to summarise the outcomes.
I need to find time to re-read or read the situation for multi_report. it was working perfectly before I upgraded to EE and I think thanks to the splendid efforts in this thread, i am now back to how I was (excepting the fact that there might have been a few additions/ changes to the script).
I’m rather rushing things in between domestic problems so I have not paid proper attention to Multi_report, instead wanting to get it at least running again.
Suffice it to say that I think it is all working properly, just like prior to my upgrade to EE, and I need to slow down and find time to read about this version of multi_report.
I do get proper emails and the subject line summary is working perfectly. I simply need to pay attention to the script options which - sorry - I am yet to do.
I’ll have a proper go at it tonight and I’ll edit this post to confirm.
edit: all OK. I’d forgotten the impressive the flexibility of the script but a quick read through the excellent documentation meant I could see that it’s all set up the way I want it.
i would be really glad if you can point me to fix eventually critical issue regarding the send-email function i provided, for the sake of the community (and to lighten the load on Joe’s shoulders).