One frustrating shortcoming of accessing SMB shares from macOS is the default failure of directory indexing for file searching. You simply can’t use the normal Finder “Search” field to do anything. This makes it particularly tedious to interact with large SMB shares when you don’t know exactly where the files you want are located.
The solution at the link is simple, if obscure: select the
fruit object from the available VFS Objects under the Advanced configuration of the share in question. Thanks to Spiceworks user David_CSG for dropping a hint about vfs_fruit that led me to this solution.
Edit: turns out that this doesn’t actually work. The current state of enabling SMB server-side indexing under FreeBSD appears to involve running Gnome Tracker. These instructions apparently work under FreeBSD Jail with the addition of devel/dconf dependency. iXsystems development stance is currently “Nope”. I might take a look at this and see whether the installation can be pared down; with any luck it should be possible to exclude metadata indexing components with the largest dependency footprint.
I have a personal quibble: FireWire may be a dead product, but there are a lot of legacy devices out there (mostly in the audio world). The current-generation Thunderbolt–FireWire adapter is completely inadequate for these devices, for two reasons: 1) they’re an end-of-line device, meaning they don’t daisy chain, which makes them difficult to use with devices that have few TB ports and 2) they are limited by TB power delivery maximums to only 10W, which many FireWire legacy devices easily exceed when operating on bus power. As an example, I have a not-that-old FireWire audio interface that I’d like to run off bus power from my laptop, on the go. It draws 7.5W idle, but spikes over 10W during startup (charging capacitors, I’m sure). I can’t use it with the TB bus adapter, I need either DC power (dumb) or a second adapter (since like good FW devices this has two ports for daisy chaining). The DC power port went out a while back, so now I use an Original iPod FireWire charger on the second port to deliver enough power.
It would be nice if anyone offered a powered FireWire adapter that could deliver a lot of wattage for legacy devices.
This is the first installment of a new segment titled InSecurity, covering consumer-relevant business and government security practices with an emphasis on their failures.
Each new week, it seems, brings a new corporate or government data breach or operational security failure to out awareness. This week is no exception. The failure this time, however, is particularly egregious: ever the course of eight months, Panera Bread Co. knowingly failed to protect sensitive customer data from unauthorized access. This data included, according to security researcher Dylan Houlihan who originally discovered the vulnerability, at least one web API endpoint which revealed “the full name, home address, email address, food/dietary preferences, username, phone number, birthday and last four digits of a saved credit card to be accessed in bulk for any user that had ever signed up for an account“. Equivalent vulnerabilities were eventually discovered across multiple Panera web properties.
Houlihan first reported the issue in August of 2017, reaching out to Panera’s Information Security Director, none other than Mike Gustavison. No stranger to “managing” wildly insecure corporate systems, Gustavison worked as “ISO – Sr. Director of Security Operations” at Equifax from 2009–2013. After eight months of repeated attempts to convince Panera of the severity of their security hole, Houlihan reached out to security industry expert Brain Krebs, whose influence was able to extract mainstream media coverage and a formal PR statement from Panera. Incredibly, and despite public statements to the contrary, Panera failed to secure the vulnerable API endpoints.
For a full explanation of the vulnerability and a timeline of events, reference the primary link.