Am I wrong in thinking that I was expecting NVME SMART reporting in EE?
In order to minimize possible regressions and testing requirements, the decision was made to focus on the one issue that was causing upgrade problems for a number of users. The IP issue has a relatively simple workaround that was documented with the RC.1 release notes.
Application Web UI buttons, accessed from the Application Info widget, can default to a 0.0.0.0:port address after app install or restart (NAS-131308). Refresh the browser window, or manually access the port in the form hostname or IP address:port, to correct button function and access the app UI.
Once the proper IP has been established by refreshing or manually navigating to it, the button continues to link to the correct address, which is what @Chris_Holzer seems to be experiencing.
NVMe disks should be showing SMART test options on the Storage > Disks screen in EE.
thank you. i was confusing the multi-report functionality with TN
Upgraded from RC.1 to RC.2 and had a boot issue with Grub:
error: unknown checksum function 0.
alloc magic is broken at âAddressâ
Turned out I had secure boot enabled. I disabled it to get it to boot, but will look at it when I have more time.
Thanks so much for that hint - I am not really familiar with all the different tools in the Docker ecosystem.
Deploying
- onlyoffice
- peanut
- uptime-kuma
went without a hitch. And I have an (apparently) read-only status display of all apps deployed via TrueNAS and full management of all deployed in Portainer.
One question, though, if you happen to know:
Are these resource limits only for the Portainer application itself or are these what is allocated to all apps managed by Portainer in total? Or for each dependent app individually?
Which âknobsâ exist in this part of the system to get individual limits?
Thanks!
Patrick
EDIT: found it - Advanced container settings | Portainer Documentation
If you want a more low level experience ;), you can try Dockge too, itâs essentially a glorified compose editor, so you can just point it at your âstacksâ directory and then manage the stacks with Dockge, or CLI, or even VS Code etc
I cannot quite point at what makes me experience TrueNASâ interface as more clumsy/complicated for custom apps. Just a gut feeling. Portainer feels mature and cool.
I am not intending to move any of my core productive installations like e.g. Nextcloud from FreeBSD jails anywhere. The SCALE system is for applications that do not manage critical data and are more pain to deploy in a jail than in Docker. @victorâs scripts help a lot to run e.g. MineOS on FreeBSD, but still. Onlyoffice on SCALE is way less hassle.
That being said I would love the iX app catalog to grow. I donât understand why e.g. Onlyoffice Document Server is still missing. Itâs the preferred MS Office integration for Nextcloud. Beats Collabora on all criteria I care about.
Kind regards,
Patrick
Thank you, however looks like things didnât go well.
8 apps successfully migrated.
Plex failed to create migrated app due to Field was not expected\n[EINVAL] values.storage.logs.type: Invalid choice: tmpfs\n
. Looks like having Plex Log and Transcode Storage in memory is not supported on the docker version of the app or just a bug?
14 apps failed to migrate due to cannot promote dataset outside its encryption root
Also, migration invalidates TailScales API key even after restoring to DragonFish. This is however more a feature than a bug I think.
Should I create Jira issues for all of these?
- Migration script not waiting until passphrase encrypted Applications dataset is unlocked before running.
- Plex fails to migrate if storage is set to Memory.
- Migration failed for âcannot promote dataset outside its encryption rootâ.
Not from my experience, at least here on Firefox. Itâs very much reminiscent of SCALEâs other GUI issues that are only resolved by a hard refresh (CTRL+F5) except that doesnât resolve this one.
Cheers for the explanation r.e. why the fix wasnât included.
Iâd take the view that if you have an encrypted applications dataset that I would not expect the migration to run on this without it being unlocked. So I donât believe that requires a ticket.
The other 2 I would recommend you raise tickets for.
Same issue here after upgrading to RC2 from RC1.
Needed to get things working again - rolling each app back brought them back to life (and then I was able to upgrade to latest again after).
Iâm not saying it should be able to migrate an encrypted applications dataset that is locked. Saying it should not run until it is unlocked/decrypted. It just seems like an oversight to me since an unencrypted dataset and a decryption key based encrypted dataset would both be available at boot. Just not a passphrase based encrypted dataset.
Edit: I just added my migration issues to thisâŚ
https://ixsystems.atlassian.net/browse/NAS-131561
It seems that the developers did not considered that the application dataset could be encrypted. Indeed why? I can understand encrypting the data, but the apps?
This seems still weird to me, does noone know how to fix it?
Itâs a bug maybe? When you unset your pool you can see that the datasets are still there by running zfs list
. Just remove them.
Unsetting is not removing relevant datasets.
Deleting the app doesnât delete the app data. The default path for apps in Electric Eel is here:
/mnt/.ix-apps
You can either delete the app data from within that directory or reinstall the app in a host path you have (more) control over.
What @rambro1stbud said. You could also just install the app using a different container name (accepting that will leave some cruft behind).
The stable release version will add a checkbox to clean up the iX Volumes:
Great, thank your all for the answers!
What are the expected default Samba create/file mask and directory mask in this version? Docs and tooltip in the UI mention 0666 and 0777.
However, from a quick test, this does not seem to be case.
Changing the values to 0666 / 0777 in the UI does seem to work though, even if this is supposed to be the default�
/etc/smb4.conf
on a fresh install shows create mask = 0744
and directory mask = 0755
. This does not appear to match docs or the tooltips.
Looking at the code, the defaults also seem to have been changed in this refactor PR? NAS-128754 / 24.10 / Refactor SMB and Directory Services plugins by anodos325 ¡ Pull Request #13640 ¡ truenas/middleware ¡ GitHub (now in util_smbconf.py
, previously in reg_global_smb.py
)
Iâd just appreciate some clarification on what the defaults should be.