Ad-Man-Gamer

They don't need to make special software for this. What they need to do is add an option for an SMB share to be configured to be more application friendly on the client. Then you can use the backup software of your choice.

Just like to add to this for clarification. While this may not help yourself, As your file system is different, it may be useful to someone else, and is what I did when I accidentally removed the server from the dashboard. If your previous server used ZFS, All you need to do is remove the discs, Run the setup with no extra storage discs, then, Once complete, Reinsert the data discs. Then go to the truenas admin panel, storage, and click the import pool button at the top right. To then make the web UI aware of the pool, all you have to do is rename the pool to "HDDs" Though, you should always back up beforehand as a matter of good practise. (What can go wrong, will go wrong). This will just save you copying the data back and forth.

Having a Application Use option when setting up a share would be grate. What? SMB is grate, but if you want the network drive to work with applications using it for there data, you need to config samba so it can use SMB features like Hardlinks, Symlinks, Space pre-allocation, and partial file writes. You basically need SMB to more closely mimic a file System so programs don't get tripped up with an IO.Write error when it try's to do something SMB has not been configured to do. You also need to lax the security because on windows, user, admin and system are all in them selves classed as different users. So if you set up your share on a user account, and the app is ran as admin, you end up with the app not being able to see the share, or will write new files as nobody, Creating incoherency between running the application as a user and as administrator. The more lax security and promiscuous permissions however means you do not necessarily want your data on the same share, or need to rely on client restrictions instead so only one IP can see and use it. Having a tick box stating that a share is intended for application data would be grate. It should then force you to enter the address of the PC that can access that share, and set up the more promiscuous SMB settings such as allow wide links, Unix extensions, Nobody user and group mapping, the client restriction to that one ip address and various other samba configurations for samba and that share, fully opening up SMB's Capabilities. Why would I want this? Glad you asked. there are Two common scenarios where this is very useful. 1. NAS steam library. 2. NAS backup location. One common use case of setting up samba in this way Is to set up a share as a steam library. When fully opened up, Steam will, quite happily, use a samba share as a Steam library and works mostly without hiccup. Another reason you may want to do this is for backup applications. Backup software loves symbolic links and hard links, and utilise them heavily to cut down on back up size and structure the backup data to be accessible from one easily clickable folder. Backup software also likes the partial file read and write support so it only has to update what's changed.

🤣 Sorry, I tend to run off explaining things in detail... I'm no master either, just a Tinkerer who knows just enough to be dangerous. I just know Proxmox handles virtualization and hardware very well, and makes handling them easy with a good GUI, and Hex/TrueNAS is doing the same for NAS/Home server stuff. If you can get them both to play nicely without convoluted Loopback configurations, you've got chocolate and peanut butter. I'm mainly supporting hex because I like the idea of paying for a simple appliance OS where you bring your own hardware, And don't need to worry about the appliance vendor dropping support. Got burned By that when I bought my Thicus NAS years ago. I also know I know just enough to be dangerous, so, letting the responsible adult handle what's important seems best. 😜

There is one reason you would do this. If you are running something like proxmox, and the hypervisor is already handling data and redundancy on the back end, (ZFS/CETH). You there for do not need that to be handled by the NAS os, You just want the NAS to handle things like SMB/CIFS, NFS, FTP, Permissions, apps, services etc. I know there is a way to have TrueNAS Virtualized, pass the storage over with pass through to handle all The storage system, Then pass them storage shares back to the hypervisor for use in other VMs. However, you then start getting into spaghetti configurations. You're better having that storage handled closer to the metal, and have the virtual machine take the datasets/Zvol's/VHD's it has been given To handle everything else it does well. From what I understand, TrueNAS is ZVol/Dataset aware, Especially With QEMU Additions. So there's no reason that Its storage systems could not get out of the way when it recognizes its handed a virtual disc. It can then just give a warning stating the NAS OS May not be aware of Potential SMART Reports, Cannot check the integrity of the back end, And to only do this if you're sure the back end is handling everything correctly... Basically, Here be dragons, continue with caution.

It would be fitting to have some kind of community plugin system (HexMods). What is a HexMod? A HexMod is simply a scripting system for creating a pseudo application for HexOS. A HexMod is simply a config file for a non native HexOS application, that points to all the relevant binarys, and their various configuration files on the server, and allows you to script out their configurations into categories, and fields available for input or option selection. Let's look at how a hex mod would work in practice. There's a game server that you want to run. However, it does not have a HexOS Application, Nor would the developer seem at all interested To do so any time soon. The game is popular and a community member decides to make a HexMod script to plumb the software into HexOS UI, Allowing for simple configuration and sensible defaults. The hex mods script First outlines what the software is, and where the dependencies can be downloaded and installed. If it's available as apt Package that is easy enough. [HexMod] version = "1.0" Title = "Game X Server" [Package] Type = "apt" Name = "gameXServer" Now you need to let HexMod know where the relevant config files are. [CFGs] Dir = "/etc/gameXServer" File = "config.cfg" Encodeing = "UTF8" This is what the contents of the file is. config.cfg ## Game X Server CFG ip= port= host= godmode= difficulty= Now you need to let it know how to read the file. [Tokens] Comments = "##" EQL = "=" Spaces = FALSE Next = "/n" Structure = [ ~NAME, ~EQL, ~INPUT ] ## Or just load a recognised default. Type = cfg Now you layout each variable, what it is, and what are it's accepted inputs. [Types] ip = ~Network(IP4) port = ~Network(PortTCP) host = ~Network(HostName) godmode = ~Bool["true","false"] difficulty = ~Option["easy","medium","hard"] Now all you do is let HexMod know how to lay out the GUI in the Control Panel, And what switch belongs to what variable. [GUI] Network = { ip = { Title = "IP Address", Type = "Network.IP4", Dis = "Server ip address"} port = { Title = "Port", Type = "Network.Port", Dis = "Listening port for the server." } host = { Title = "Host Name", Type = "Network.Hostname", Dis = "Host name for the server." } } Gameplay = { godmode = { Title = "God Mode", Type = "Bool", Dis = "God mode makes all players invincible and able to fly" } difficulty= { Title = "Game Difficulty", Type = "Option.Dropdown", Dis = "Set the difficulty of the game", Option.1.Lab = "Easy", Option.1.Dis = "All playsers cant die.", Option.2.Lab = "Medium", Option.2.Dis = "Players can die.", Option.2.Lab = "Hard", Option.3.Dis = "Players can die enemies hit harder." } } This will then create an application icon named "Game X Server" in the UI. When you click it It takes you to the configuration page. You get two expandable categories in the UI, Networking and gameplay, With each field having their respective restrictions for what type they are expecting. The HexMod then enters those values into the .cfg for that application and saves the file. HexMod also notices some flags are part of its capability to handle some auto magic on the back end. Such as the Network Types. It binds the application to the IP stated, and also sets a firewall rule accordingly for the port used. You can even have more advanced stuff like pointing to the server binary to also allow for restarting of the service, as well as scripts... The basic idea is the community can make these things pretty easily with scripting if they know how, and every day users who aren't into the technical can just take an off the shelf HexMod a community member has made. HexOs then does all the auto magic in the background.

This would be good. But there are a LOT of games out there. This would seem something more fitting for some kind of community Plugin system (HexMods). Those in the know can quickly mock up a gc file, (Graphical config). It can be something like a xml or JSON file. in the file, You can list the config switches and there expected inputs. add descriptions, categories them, tag networking related entry's to also pass on to set up the back end, and points to that game servers config file. The gc Engine then passes this config and auto generates the GUI In the standard layout/formatting for hexos. Forgive the pseudo code. If you have a .cfg file with the following options. gameserver.cfg ip= port= host= godmode= difficulty= You then map out the GC file and each string value in the as follows. [Title] {Game X} [Cfg] {/etc/gameserver.cfg} [Network] { ip=~IPv4, port=~PORT, host=~HOSTNAME } [Gameplay] { godmode=... ~INPUT (INT 1,0), ~TYPE (BOOL TICKBOX), ~DIS ("Makes all players invincible, and able to fly") difficulty=... ~INPUT (STR easy,medium,hard), ~TYPE (OPT 3 DROPDOWN) ~DIS ("Select or difficulty.", O1="All playsers cant die", O2="Players can die", O3="Players can die enemies hit harder." ) } This will then create two expandable categories in the UI, Networking and gameplay, With each field having their respective restrictions for what type they are expecting. The GC Parser then enters those values into the cfg and saves the file. You can even have more advanced stuff like pointing to the server binary to also allow for restarting of the service, as well as scripts... The basic idea is the community can make These things pretty easily with scripting if they know how, and every day users who aren't into the technical can just take an off the shelf plug in A community member has made. Hexos then does all the auto magic in the background.