If there is one piece of feedback to consider: at the beginning of the setup process, see if the config file can even be created? If not, tell the lugnut at the console that while going through the setup process multiple times might be fun, it might be less work if the config file can be saved.
Ie something like try and create the config file and read it back. If nonexistent, stop the config process with an error message.
@joeschmuck I followed the outlne for updating, editing the config, saving the config, running Multi-Report to create the disk layout file. All worked fine. I uploaded one the config file to the Disk Layout configuration page without issue and even created a layout using most of the drives. I noticed it basically for my system went in order for my systems layouts. Why did I use most drives but not all you may ask? There was not a default layout for either of my actual in use systems that I could accurately place all the drives in. I would suggest if possible to add at least these two additional setups:
First layout example is a 36 Bay chassis with 24 front and 12 rear bays. I suggest this: Front and Rear rack mount chassis with Front and Rear variable in amount to accommodate amount of bays in front and rear. Supermicro makes various chassis like this.
This is the second layout is a 12 bay Front, 4 bay internal, and a 2 bay rear. What I suggest is: Front, Internal, and Rear bay layout and again, make each section variable amount of bays to allow for flexibility in layout. This is also a Supermicro chassis.
Thank you for the hard work on this and the associated Multi-report and config page.
Funny but yes, this can be done. I will roll that in today since it is easy.
@PhilD13 Having multiple and customizable layouts are coming. We wanted to put this Beta out to solicit feedback and to check if the script works on several different systems. With that said, it all will take some time.
Beta Update
Please check for updates manually using -update every few days to grab any Beta updates that may have been uploaded.
Sounds good!
I did run into an issue where there was an error generated. appears to be missing a file. This is in 3.26 pulled from earlier today. Iāll look at the log and see if it is my fault on something.
Saving Log (file name: /mnt/Pool1/general/scripts/multi-report/DS_Logs/drive_selftest_04.txt)
Zzzzā¦
Exiting Joeās SMART Drive Self-test Script
Collecting Multi-Report Dataā¦
<><><><><><><><><><><><><><><><><><><><><>
<> Drive Mapper - Error <>
<> render_case had an error code = 1 <>
<><><><><><><><><><><><><><><><><><><><><>
cat: /mnt/Pool1/general/scripts/multi-report/case_email_snippet.html: No such file or directory
Using sendemail.py
Email sent
Edit: Ths is the error from render_case.py running in Truenas 25.04.2.6 (which may make a difference):
root@serv1:/mnt/Pool1/general/scripts/multi-report# python render_case.py
{āversionā: ā0.02ā, āerrorā: true, ādetailā: ā[SECURITY ERROR]: directory ā/mnt/Pool1/general/scripts/multi-reportā is writable by non-privileged users; operation aborted.ā}
The issue you may be having is that the directory where the script is running is not only for privileged access. If you open case_render.py (version 0.02) and comment out lines 39 and 40 or (version 0.03) I have commented the lines out, it will ignore this check.
The thought here is that if you must run the script as root, then you should be in a privileged directory.
This may be a sticking point for people, I realize this. It would be nice to hear feedback on this.
EDIT: I will post an updated version of the files tomorrow. Look for a message that case_render.py has changed to version 0.03. This is how I will let folks know there is a Beta update. You will need to update both multi_report and case_render.py. They are linked together. This will not affect anyone not using the Beta Disk Layout feature. Ands I know this may be a little confusing, but please bare with me.
Thanks. I was just about to post I figured it out.
I was able to adjust permissions on one server for the directory and I ran the case_render.py as standalone to figure out what the error was earlier today. The other server I was able to get to work in a similar fashion but I think I will just move scripts to a new dataset where things going forward may be happier.
As far as what to do. I would suggest at this point you disable the check for now, at least while new features are being tested and proved. It may cause a lot of unnecessary tech support for the script over the check.
Not worried about the having to run a couple scripts to pick up the latest beta
Personally I stuck the scripts directory under an accessible by everyone smb directory with open permissions quite awhile ago. It is just me and one other person using the servers and they raise holy hell if they have to log into a server share. Its not like I have to secure it like fort knox anyway so its open.
This openness seems to mess with some things. Also some things like the Dolphin file manager/browser might show the server under the SMB network section but it likes to apparently default to anonymous as the user with no password when connecting and later I can be somewhat of a pain to make it use a user/password.
First of all, thanks for taking the time to do these tests!
I would spent 2 words about some background that led to some decisions made.
the render_case.py not require any fancy permission itself, instead the multi report run with high privilegiesā¦ this can be a dangerous mix. The stake ā[SECURITY ERROR]: directory ā/mnt/Pool1/general/scripts/multi-reportā is writable by non-privileged users; operation aborted. have the intention to give end user a strong advice that the tools are placed in a really unsafe location. From my point of view, precisely because we are in BETA, this shouldnāt be skipped and instead must be evaluated deep, as much as it may seems unecessary.
as nice as he would be really good have a case layout for every situation, objectively this will be not possible, combination-uses cases are too many. Said that, is also true that the actual case layout list is still āpoor of elementsā.
The actual layout is capable to handle a max of 48 bays, spread on 4 columns - 12 rows. This is what he looks to me as a sweet point to accomplish moste uses cases, without be too much dispersive for people with small system, but that could somehow accomplish system with a lot of disks; in this version i canāt assure that every use case can fit perfectly without some compromise, and this beta start is also important to understand users needs, and which direction to take.
```
| Col 1 | Col 2 | Col 3 | Col 4 |
|------:|------:|------:|------
| 1 | 2 | 3 | 4 |
| 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 |
| 29 | 30 | 31 | 32 |
| 33 | 34 | 35 | 36 |
| 37 | 38 | 39 | 40 |
| 41 | 42 | 43 | 44 |
| 45 | 46 | 47 | 48 |
```
@PhilD13 donāt know if you already try it, but the Full 48-bay case layout should be the one fit better your needs:
@zzzhouuu chose a smaller case, with only 4 disks i would suggest the Mini Tower 4-bay, donāt get confused by names, focus more on bays availableā¦ also names and desc should be fast improved 
In my ideal world, Iād be running multi-report out of jail maker jail but jail maker only has a few more editions before it too gets excised from TrueNAS, no?
Plus, is SMART access / scheduling / email / etc. even possible from within a jail?
@oxyde Thank you for you work on the project.
I run it out of what amounts to an insecure area yes. But I did comment that it might be better for me to make the script itās own dataset so I can apply correct permissions to the dataset and have the script in a more safe location. After all that is one purpose of datasets
I did not try it yet. Yes I think that would work. I will give it a try. If you make a separator in the future like you describe, could you add a way to add a Title or note to the separator. Then a person could designate location in a chassis of Front Bays, Internal Bays, Rear Bays by adding a note.
A better idea is to make 3 pre-made separators (Front Bays, Internal Bays, Rear Bays) and a 4th separator as a blank separator that can be selected by the user and dropped in the desired row. That would likely then cover most use cases rather well.
I have updated the Beta, if you are testing it, run -update_all to grab an updated copy of multi_report (the version numbers will remain the same) and case_render. I know some will not like the version number of Multi-Report not changing for this Beta testing, but there are people not doing the Beta testing and they should not have to update Multi-Report due to a change that only affects the Beta portion of the script.
I have disabled the security check for the case_render.py. If you are using the script then you already realize the risks. And I too fell into that group of having the directory fully open to everyone. I made a small change, it doesnāt affect anything for me in my situation, so all is good again. But having the directory a little more protected does make sense if there are multiple users.
The update addresses people who use MS Outlook as the rendering of the HTML CSS code is not supported, so we had to make it more generic for this app. There is a new switch in the config file MS_Outlook=ādisable" which when changed to āenableā will change the imbedded code, however the current Disk_Layout attachment will remain the same, as of now.
As @oxyde has said, this is a Beta, we are gathering information and @oxyde has been helping me out greatly with the generation of the HTML chart.
Just so people know, in my mind I wanted to take a photo or diagram of the case and superimpose the drives on top of that. That is not as easy as it sounds. Will we ever get there? I have no idea. I also want to be able to rotate the drives 90 degrees but that also is not an easy task, keeping in mind we are doing this in our spare time. So please provide feedback but understand this is a slow process and it may not be a perfect solution for everyone, and it will take time.
Itās just a bash script with some external added python scripting and so has certain user and permission requirements. I think there are some as of right now root user requirements set by Truenas to access certain system parameters and do certain operations which may be difficult to access in a different way. Much like if on the command line you need to use SUDO in front of certain commands. Then there is the factor of trying to convert current direction and functionality into something like an app or to an app which takes learning a new system and more time and the risk of an app base changing completely down the road when the next wizbang thing comes along.
Some news for people that are tryng the disk layout editor in beta
Not considering some refactor here and there, with the latest commit is also available
Prebuilt case models will be still available (we will add more very soon!), but we see them more as a base to be picked and then adjusted around every use case. We hope that this strategy will give to everyone the output they desire with few interactions.
Let me know every concern - problem you encounter and suggestion!
Version 3.27 was just pushed to GitHub. This provided a few small fixes.
The Beta of Disk Layout is still in operation and @oxyde has indicated. There is more work to be done on this new feature but it will generate a nice drive layout image which will show you where your drives are physically located. If you try this new feature out, please provide constructive criticism so we can make it reasonably good. We still have a bit of work to perfect it but your feedback will be helpful.
New version with the disk layout works great for me on the newest pull provided that I remember to restrict the permission after using smb to drop in the disk layout file.
It looks super good. Something awesome is now even MORE AWESOME.
Thanks for all the hard work!
It is a team effort.
The Disk Layout feature is maturing every week. I will push a special version of v3.27 Beta to GitHub. This will operate the same as the official 3.27 however the Disk Layout will be updated.
The next posting should be by Friday. I have some testing going on and once it looks good, or good enough, I will post it in the Multi-Report repository.
This project could take a month or two to iron out all the details, but more changes are coming.
If you or anyone else has feedback, please open an āIssueā on GitHub so we can have it recorded in an appropriate place and we accept the good stuff and the bad stuff. If you have recommendations, please make them, keeping in mind that we cannot, or will not add some things. It should be beneficial to everyone, not a niche item. But it never hurts to ask.
Recent rendering in the email (after the latest published drive beta updates) is a large aprox 2 x 2 square for each filled drive position and there is lots of space between lines of text. The earlier beta version(s) the drive positions were much smaller and rectangular.
Big boxes:
Smaller boxes from an earlier version:
@PhilD13 That is quite odd and yes, should not look like that at all. The box size should be similar to what you see in the Online Disk Configurator.
With those very smart words said, a few questions:
Change the MS_Outlook value to see if the box size returns to normal or not.
I am assuming you are using the same email and email client as this can wreak havoc, hence the Outlook version.
While Iām waiting for the script to finish the second test run and send the email, I think I figured out the issue and I have a hunch about something in the script.
This is what is running on both machines.
Email client is: Thunderbird 140.3.0esr (64-bit)
email setup has not changed
Multi-Report v3.27 dtd:2025-11-14 (TrueNAS SCALE - Fangtooth 25.04.2.6)
Multi-Report - Installed: 3.27, GitHub: 3.27 - No Update Available
Drive-Selftest - Installed: 1.07, GitHub: 1.07 - No Update Available
Sendemail - Installed: 1.71, GitHub: 1.71 - No Update Available
SMR-Check - Installed: 2.0, GitHub: 2.0 - No Update Available
Disk Layout (render_case) - Installed: 0.05, GitHub: 0.05 - No Update Available
I messed with the new online multi_report config maker/editor the other day and it for some reason completely blanked out the ###### Disk Layout ###### section of my config file on saving leaving only the section header. This made multi_report not do the disk layout at all. I did not look at the config maker code yet to see if that was by design.
No problen. I just copied back manually the info below from an earlier backup but for some reason managed to only copy the first line back and not notice. The section then looked like this and was missing the outlook line:
###### Disk Layout ######
Disklayout="enable" # BETA TESTING ONLY and SCALE ONLY.
instead of like the correct section:
###### Disk Layout ######
Disklayout="enable" # BETA TESTING ONLY and SCALE ONLY.
MS_Outlook="disable" # Set to "enable" to use the OUTLOOK compatable version. Default="disable"
I just ran the script twice with the correct lines, once with outlook disable and once with outlook enable. Both emails have arrived and I can confirm that the script outputs correctly when the MS_Outlook="disable" and if it is enabled, then the outlook stuff is the issue with the oversized boxes when not using outlook. I can also confirm a bug or issue in the script as below.
This is what I have just verified:
If the line MS_Outlook=ādisableā (default is disable) line is missing altogether or remarked out then the default for MS_Outlook= effectively becomes enable for that option.
Since the online config editor for multi_report actually had removed the two lines and my failure to see I didnāt actually copy both lines back in to the config file after I discovered they were missing I managed to uncover the issue.