If you updated to version 3.17, it will fail and delete the multi_report.sh file and not create the new one in its place. I broke it.
There is an updated version in place now.
How to fix: multi_report_v3.18_2025_06_09.txt (600.3 KB)
and plop it into your script directory, rename it to multi_report.sh and that will fix the problem.
For peace of mine, run ./multi_report.sh -update and it should say you are on version 3.18 and the online version is 3.18. You can update if you desire but you would have the current version.
Sorry about the issue, I tested the crap out of the script and forgot to test the update from GitHub since I didnāt think I made any changes there. I did, I commented out one line which then caused the issue. That line is still commented out, but I added a command which accounts for part of the commented out line that I didnāt want removed.
Even if you manually installed v3.17, you need to manually install v3.18. Version 3.16 will work fine.
I updated from 3.16 to 3.18 and got the following:
root@truenas[/mnt/TrueNAS/scripts/multi_report]# ./multi_report.sh -update_all
./multi_report.sh: line 856: /tmp/memory_free.txt: Permission denied
./multi_report.sh: line 895: /tmp/memory_free.txt: Permission denied
Multi-Report v3.18 dtd:2025-06-09 (TrueNAS SCALE - Fangtooth 25.04.1)
- Update Script Routine
- Removing Old Script Source if it exists
- Downloading new script files
- Multi-Report current version is: 3.18
- The new version is: 3.18
Enter 'y' to commit or any other key to abort.
I am logged in as SU (sudo su) after connecting through ssh.
Running the script starts with the same two 'permission deniedās as well.
Those two lines are trying to create two files in /tmp/ location. I just tried to run as su and met with a lot of errors, more than you have seen. smartctl is unable to run, you get an error that the command is not found. Try to run as root.
Have you ever run this script as su and it work? If yes, we should exchange some emails so I can figure out how to make that work. Iād learn a lot.
I ssh in using the truenas_admin account. then āsudo suā (which is actually the same account). this this has always, and still can, run the script.
Actually, now that I think back (unfortunately canāt check back). I think I had these errors when running the update command to go from 3.16 to 3.18.
But it seemed to workā¦
I suspect it was an earlier version of SCALE, before all the lockdowns started happening. BUT if you are able to run as something other than root, Iād really like to hear about it. A good test is smartctl or fdisk or zpool (many application I need to run the script) and see if it finds it. Privileged commands have been locked down.
Not right now, sounds like you got it covered. I will try this out myself to see if I can make it work as well. If I can replicate it (Iām sure I can) then I will add that to the instructions.
Thank you for the information. And yes, Permissions suck!
@GrimmReaperNL
Yes, it does work, from the CLI, very nicely as well. Thanks for the education, it is nice learning something new. I just hope that with my poor memory, I can retain it for a while. My wife says I have āC.R.S.ā Canāt Remember Shit. Itās true.
It however does not, and probably a good thing it does not run for a CRON tab job. Iād recommend running it as root in the CRON tab job.
Why would it not be good, nested environmental variables or so I read. Not sure how true that is but if someone else wants to investigate the best way to run a script that requires root privileges from CRON, have at it. Let us know what the results are. I am very comfortable using root in my home lab, that is not directly to the internet.
I have not tried -i but when I get home from a horror flic with my granddaughter, I will see what happens. I donāt believe I execute from with /tmp, just copy. I can verify later.
sudo -i and sudo -s There are some differences in where the root login is placed in the root shell, but either opens the root shell and functionally I think they are the same.
exit or ctrl-d exits from (logs out) the root shell.
Personally I have used -i since sudo became in vogue so the environment is really root when validating system level tasks. If the privileged account to run the script is configured as per the documentation, sudo -i [-u user] would be the preferred route to take for validation & troubleshooting of your scheduled task. Itās unixā¦ many different ways so comes down to personal preferences.
From the manpages
-i, --login
Run the shell specified by the target userās password database
entry as a login shell. This means that login-specific re-
source files such as .profile, .bash_profile, or .login will be
read by the shell.
Thanks for all the hard work on this @joeschmuck. One question - Does this latest version of the script (v3.18) make changes to the Spencer integration? I havenāt been getting the Spencer information listed in my automated email since this latest upgrade, although I can see that the spencer.log file is being updated indicating that spencer.py is running every morning as part of the multi_report cron job. Any thoughts?
@Filtering58 No, no changes at all, that Iām aware of.
If you donāt mind, I will be sending you a message outside of this thread so we can see what is or isnāt going on, and once we figure it out, post the results here for all to see. Iām trying to minimize the huge size of this thread. Anyone who wants to read it should be reading the first posting and then the last few postings, well that is what a smart person would do.
And if you do not mind sending me a dump using the -dump email switch and put some blurb of a message when it asks. This means I would know your actual email address, but as others could attest, I donāt share personal information. If not, you could run using the -dump switch, then sanitize the multi_report_config.txt file of your email address, and then send me those in a message in the forums. It is significantly easier to just send me the dump directly but that is entirely up to you.
In the meantime, I will check to see what may have changed in the update. The config file changed a lot and I could have caused an issue there. I hope not but I will assume I caused the issue until we can prove otherwise.
To update the readers on this development. @Filtering58 was referring to the CronTask Run email which is generated by the CRON job. I did make a small change in V3.17 to hide some of the cron job outputs in an effort the minimize extra garbage. The relevant data (in my opinion) is in the Text section of the Multi-Report report. If it is determined that more data should be added, I will make that change for the next version.
I provided the single line change information and @Filtering58 is now seeing the Spencer run output in the CronTask Run email like he was use to seeing before.
What this shows to me is Spencer absolutely adds value, if you donāt use it, consider looking at it to see if you might benefit from it.
Today my report has orange all over it. For my spinners, all the Power On times are now highlighted, together with the Temp Max for the drives that have hit 55*C in the past.
For the NVMe, the 2 sticks that are my Log VDEV are flagged with Last Test Age of 2. Not sure if this is genuine or not, as Iāve never seen anything other than 0 for these.
@EddieA Would you please run the script from the CLI and using the -dump email switch so I can see what is actually going on? Iām sure it is a simple thing to fix. Also, if you have an email report using 3.16 handy, especially with a copy of the multi_report_config.txt attachment from that run, forward to joeschmuck2023@hotmail.com and I can do a comparison. If you do not have a copy of the old multi_report_config.txt file, there should be a copy in your script folder called something like ā2025_xx_xx_Old_3.16_multi_report_config.txtā and this is a copy of that old file. Do not delete it, if you need to roll back to v3.16, you would use this file.
I can provide a full explanation on what happened, even if I say I screwed up.
