Not what i would hear, at least for the MR send 
Iām registering to emailsender and i will make some test on my system.
Meanwhile for the testmode, can you confirm that using this command:
midclt call user.query "[[\"uid\",\"=\",$(id -u)]]" '{"get": true}' | jq -r '.email'
do you see the recipient email of the root user?
Alright thanks!
If i run the command as root I get null, if i run it as truenas_admin I get the address
ok this is a minor issue 
basically the testmode grab the email of the current user, if you are using the root and no email is set here the error. If you go into the TN GUI Credential --> User and set a proper address (i think can be the same of the truenas_admin) the testmode will start working properly.
I will update on the other things soon
@oxyde is managing the web pages for the configuration, he deserves all the credit for the nice sound effects, and basically the entire layout.
The original purpose of the Disk Layout image was just to help locate a physical drive by serial number. It grew a little bit.
The Disk Layout feature is not perfect, and honestly I donāt know if it will ever be perfect, but we will try.
Thanks for the feedback. I like constructive criticism, and soon everyone will be able to provide some more when I release the next minor version update hopefully in a few days. Okay, I actually hope for no problems at all, but it rarely works out that way.
@shady iām sorry but i donāt think i can do more. After setup a test account with them, i have your exact same behaviour.
To me really seems that emailsender is make fun of us and rejecting every attachment with specific extensions (and not for the reason they provide in the error response):
they are a transactional email marketing service, and this seems reasonableā¦ but not compatible with this use case. I would really suggest to connect your nas with another provider 
Gmail (as you previously mentioned) works very well.
I switched to Gmail and now everything works fine, thanks for your time!
glad you are now up and running, i would liked be able to get mailersend work reliably but i really dont figured out how 
Meanwhile i have opened a ticket to them, hope they can confirm or not the behaviour.
I still will keep the enhancement made on attachment side, so at least we have gained a little improve sendemail side
@shady just to put a lid on it, good you switch provider because mailsender is not viable to use with multi report:
Have to admit that theyr ai bot answer me really quickly, but at start he stated that was fault āmy sideā, and after have provided a lot of info (example, code, ā¦) in some interaction he stated this.
Also, since they show an error message but itās actually something else, it smells a bit fishy to me
@oxyde
Should I add an option to send the entire email in a ZIP file? I donāt think many people would use that but some might. If it appears that some folks want it, they need to speak up so I can add it into the next major version, due out next week. 
That was a joke, it will come out hopefully in 2026. See, Iām just a clown today.
Keep it up and we will think winnielinnie took over your account
@joeschmuck jokes apart i think that i can achieve this directly into the sendemail, if a library Is present ofc; then for mr will just a āput this arg to zip everythingā
I can easily make MR zip it all up, but for SCALE only since SCALE includes 7Zip. In CORE, I had to get MR to install 7Zip and then add a symbolic link to the file. It was easy but I have removed this support from the CORE version.
With that said, if you had a switch like maybe -zip or similar, and then zip the entire file, keep the Subject line the same, and add some plain text that states the attached zip file contains the report and all other attachments. I have no issue with that as well. In MR I would setup a new variable, maybe called zip_entire_report="enable" and then I could use the -zip switch when calling the python script.
This is just spitballing the idea. I really donāt think many people would use it, however, I could be wrong.
Itās interesting, even though multi report executes as expected, I get this error message every time it runs.
I thought I followed the instructions to a t, any idea how I managed to mess it up this time?
The command:
cd ~/MultiReport && ./multi_report.sh
Produced the following output:
sudo: process 4190689 unexpected status 0x57f
This is a permissions issue. It was documented a few monthās ago in this thread. Iād look it up but my smartphone and fingers donāt work well together.
Apologies, I will look it up!
It is an ACL issue, I donāt recall all the details off the top of my head. I like Unix permissions but ACLs are more restrictive I guess.
Guys, such a great tool, with web editors, major props to all!
Iām trying to understand how the read/writes column for the two mirror-0 ssd drives can be so different. It almost looks like theyāre swapped. I did allow the script to reset the history during the install, and ran a replication on their pool. Doubt itās related, but the nvme2 drive constantly flip-flops itās dev location with the OS nvme1.
scale 25.10.1
This should not happen unless you are rebooting or powering down and then up again. If it is happening and you are not rebooting or powering the machine down and up again, then you have a real problem. I have never heard of that happening before, but hey, I get surprised every day.
When powering up/rebooting, the first drive to be recognized by the OS gets the first Drive ID.
You should restore the drive serial numbers column, drive models that are the same will get confusing. But you can look in the Text Section and still get the data.
Letās play out a scenario:
You power on the machine, nvme0 = WD Black serial number ā534XYZ7ā (made up for example), and nvme1 = your 128GB drive, nvme2 = WD Black serial number āOU812ā.
Odds are that this will be the assignment each time you power on the computer.
Now you instead Reboot the computer, all the drives are initialized and ready for the OS to see what is out there. Now the system makes this assignment: nvme0= your 128GB drive, nvme1= WD Black serial number āOU812ā, and nvme1= WD Black serial number ā534XYZ7ā.
Odds are that everytime you reboot the machine, it will come up using this assignment.
It is a millisecond race to which drive is ready to support first. But it has nothing to do with Multi-Report, I just report what is the current configuration. This is why tracking by serial number is very important when you are relating a drive to a physical piece of hardware.
Thks for confirming that, so donāt use device ids for post-init scripts. Itās been powered off more than on for setting up things, but plan to operate on much the same schedule. Maybe not a good idea for thermal cycles, but it could be off more than on each day.
The SN column is in the emails, just tried to reduce the table width.
