Welp, I have never seen a bug report get closed so quickly. Unlike @Captain_Morgan, the triage team considers it a duplicate to the previously submitted bug report.
Unless the SMB default share purpose issue re ACC was investigated separately (which I have no insight into) then it might be premature to close the bug report as duplicative.
Hope everyone else is having a great Friday. Cheers.
I think the team considers the two bug reports you submitted to be part of the same issue.
It seems likely to be true, but its not clear whether or not there is an underlying bug (or how obscure it is). It will be more obvious if a second system exhibits similar issues.
Absolutely. I’ve always been a strange attractor re IT issues at work, a previous Dell laptop would randomly fire off thousands of CTRL-Z commands and undo hours of work before my eyes. Went all the way up into MS support and we concluded the most likely reason was metal dust contaminating the keyboard. It’s a work related hazard.
New laptop solved that issue, along with keeping laptops closed at lab and in stands, especially while cutting metal. Plus we mostly cut metal outdoors now.
Had a look at my last CORE config file anno 2024-06-06 prior to DF upgrade using BBEdit. All SMB share names end with NO_PRESET except the Time Machine ones. I do not seem to have the right BBEDIT encoding set for the DB file, however, as some of the following characters appear to be random, which I am sure they are not.
Prior to my upgrade from DF to EE, anno 2024-09-14, the SMB share names end with DEFAULT_SHARE{“enable”: false, “watch_list”: , “ignore_list”: }
My BETA upgrade-to-EE RC1 anno 2024-10-02 file has share names end with DEFAULT_SHARE{“enable”: false, “watch_list”: , “ignore_list”: }
My latest config file (2024-10-12) while upgrading from RC1 to RC2 shows SMB share names that end with NO_PRESET{“enable”: false, “watch_list”: , “ignore_list”: }
So @awalkerix is correct that the SMB shares appear to have had incorrect SMB purposes starting with Dragonfish. But they still served OK, i.e. perhaps ACC was not disabled / overwritten by the DEFAULT_SHARE setting until EE? Who knows. Looks like a edge case.
Unfortunately, I have encountered the same problem. I want to run an act_runner on nas. It needs to modify daemon.json and get a lock to work properly, but every time I restart truenas after modifying daemon.json, daemon.json will be reset to its original appearance.
Start a new thread on the issue.
There may be a solution if you describe the problem at a high level.
Generally, init scripts are used to change anything at every reboot… some things are possible, but may require developer-level skills.
