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.
