The other day I noticed that I could no longer reach one of my TN servers. It mainly just holds my reverse proxy manager and is a destination for backups from my other server. It also backs itself up to the other server.
When I finally got around to plugging a monitor in to it I got these errors.
Is that going to be recoverable at all and if not how do I restore from the backup on my other TN server?
The important question - is do you have a copy of your config file? Somewhere safe, not on the NAS.
Basically your boot disk is not working well. At this point it would help if I knew what your hardware was.
Would it be named like so?
macmini-TrueNAS-SCALE-24.10.2.1-20250604073024.tar
If so, then yes, and that gives you an inkling of what my HW is as well.
It’s boot pool is a USB thumb drive, I’ve been meaning to add another volume to the pool but it hadn’t made it to the top of my to do list yet.
Case closed…
How do you intend to do that in a Mac mini, which doesn’t have much room for storage? Two SATA SSDs and that’s it; 2.5" HDDs in vaguely useful capacity are all SMR.
To add to @etorix’s “Case closed”: Do not boot from USB sticks.
If you have to boot from USB, add a USB SSD.
Just install TrueNAS fresh on one of those and restore the config file. It should pick basically everything back up.
Thanks, that’s so helpful.
I have 2 internal drives and several external Firewire drives attached to it. Works fine for its intended purpose. Maybe you noticed since I provided that info in the original post.
Thanks for the actually useful help.
I’m aware of the risks of using thumb drives, just hadn’t had a chance to upgrade yet.
I have literally never heard of someone using firewire drives with TrueNAS. No idea if thats …a good idea.
Up until this issue with the boot pool, it’s been flawless. Because the Mac hardware is so cohesive, the drives are recognized natively and seemed to be working just fine.
Once I get a chance to reinstall and put the config file back I’ll let you know but I suspect the data is fine.
I meant: “Case closed. We have caught the culprit.”
Reinstall to a diffrent media, preferably a genuine SSD on a USB adapter. If you use another USB thumbdrive, be ready to do replace it again. TrueNAS is not kind on low endurance boot devices.
Beacuse USB is a pooling interface and pooling causes disconnections, it is advised NOT to use USB for data pools. Firewire is possibly more robust… but it is also a legacy interface, so you’re the canary in an abandonned coal mine. Good luck!
Sorry, had a brainfart. I meant Thunderbolt, not Firewire. My greybeard is showing.
While I agree that Mac hardware is cohesive and typically works very well with the OS specifically designed for it, things change when you run a different OS. The cohesiveness doesn’t really transfer, instead some of the more esoteric choices Apple made can require manual alterations in kernel flags and the like in order to get it to work as one would expect.
In my past experience even SSDs on USB adapters have issues due to the performance required by the O/S. ( Ask me how I know this. BTDT 
)
In my opinion, for solid performance there really is no substitute for having a good reliable ‘boot-pool’ consisting of either SSDs or spinning rust drives (… and preferably at least mirrored.)
Drives are cheap… data recovery is not.
All the best,
Bill
For whatever reason I have usually had better luck with FireWire than USB. the Mac is remarkably backward compatible - imagine going thunderbolt 3 → T2 to FireWire 800 to FireWire 400 then OrangeLink to SCSI square and finally to a DGR 128 MO drive. Worked without any drivers!!
One option for Macs is a HBA inside an external enclosure. Brings power, etc. Can even allow for an external HDD enclosure. But PCIe Tunneling is not a guaranteed feature in TrueNas so I wouldn’t rely on it.
Plus, Tunneling is limited to PCIe x4, and 3.0 at that. As I understand it, minimum PCIe speeds in Thunderbolt 4 have been raised to 32Gbps from 16 in Thunderbolt 3, so that’s still a lot of data (4000MB/s theoretical though overhead will take a bite). But everything in that chain has to be Thunderbolt 4 to get that speed.
Between the lack of guaranteed support and the vagaries of external connections, multiple PSUs, etc. I’m not a fan of this approach even if it would allow for far more compact (and likely prettier) enclosures. Cooling in external HDD towers can also be really hit or miss, ditto the quality of the PSUs in them.
Give us the details as I run most of my systems with external USB 3.0 SSD drives (reliable Samsung) and have yet to see “issues”…
Some go to sleep daily and some turn on/off daily and no issues for years now.
Reinstalled the OS, restored my config file, and everything is up and running again!
In an earlier hardware configuration on a system here, I was running a mirrored ‘boot-pool’ with two USB attached 240gb SSDs using Sabrent USB-to-SATA adapters. In this configuration, I experienced numerous intermittent issues which usually manifested as an O/S system freeze, thus requiring a hardware reboot to recover. I narrowed the issue down to the USB attached ‘boot-pool’ SSDs. Once the SSDs were moved off of the USB adapters and over to an on-board SATA controller, all the problems disappeared.
My suspicion is that one of two things were occurring: (1) the USB-SATA adapter response was too slow to provide the necessary performance for the O/S, or (2) the USB power to the USB-SATA adapters was marginal and causing issues.
I really suspect USB port speed as being the root cause of the issue.
At either rate, moving the ‘boot-pool’ drives from USB attached to SATA attached solved all the issues here.
Depending upon your USB port speed/type (i.e.: 1.0, 2.0, 3.0, 3.2, etc.) and the USB devices used; you may not encounter the exact same issues when using USB boot devices. However it really seems to be a hardware dependent issue.
All the best,
Bill
USB can manifest all sorts of non-logical issues.
For example, for a GPS-referenced time server on a pi, I’ve had reliability issues @ USB 3 speeds with attached storage that went away at USB 2. The root cause is a known EMI issue built into the Pi hardware, where the Pi kills GPS reception if it’s anywhere near the antenna and interferes with the signal once it’s on the Uputronics daughterboard.
The root cause is the speed of USB3 being a close multiple to the frequency of the GPS signal. No such overlap at USB2 speeds.
Don’t even get me started on the absolute mess that is USB connectors and associated watt limits, throughput speeds, and so on. I always made fun of pops with his labeled connectors but USB literally forces you to keep track of what connector / cable combination can do what.
So, I try to stay away from USB as much as I can. It simply gets in the way for the NAS and that is reason enough to nuke it, if possible.