I’m trying to use a win11 PS script to unlock a passphrase dataset and don’t know how to diagnose the issue on truenas scale. I appear to have a functioning SSH connection as I can have the box return it’s host name. My unlock command returns what I assume is a PID number (instead of 0 for success?), although ps on the truenas shell doesn’t show that process.
How can I go about figuring out what truenas sees and any errors associated with the request? All I can find on the gui in Audits/Middleware are token authentications associated with SSH. I suspect it could be something like a command formatting issue, or permissions maybe. Any suggestions on how to troubleshoot would be greatly appreciated. While I’m a total newbie to truenas and all this stuff it’s kinda fun to touch unix again after many decades.
Thanks for the reply and link. I had seen that page and tried a few variations, only to realize my test script had the pass phrase misspelled. I also finally found some API documentation that removed another variable.
In the end I had the middleware commands working fine from the shell. However got tired of fighting the power shell syntax to get all the nested quotes to work through ssh. So I’m now using a simple script on truenas such that the ssh command passes only the passphrase.
If the API call is a job (which will return the job id) then you’ll need to specify -j to actually follow it until completion.
That said, you should make sure to come up with a better solution than typing it in, otherwise your passphrase is getting stored in the shell command history and/or is visible in ps output. Writing a brief script to use the python api client locally is trivial and can work around these issues.
It’s encrypted and only loaded into memory during the win11 powershell script, which passes it to a script on truenas. But I noticed each midclt command is logged in .midcli.hist and .zsh_history files in an unencrypted home folder. Is there not a way to avoid this.
This is a standard issue with using shell scripts, and can be solved in the standard ways. The midclt command was primarily written for development efforts. The correct solution is tho use the API client (which actually can work remotely from a windows client) rather than trying to run local scripts wrapping around midclt.
