But you didn’t vote for this? See vote button on top
lsscsi has been added: NAS-130189 / 24.10 / Add lsscsi by aiden3c · Pull Request #670 · truenas/scale-build · GitHub
6 Likes
Any hope for lsusb?
The good part of these requests is that merely adding the tools is expected to have no impact on system operation and stability.
1 Like
What LS* commands are missing as of today?
LSSCSI (getting added)
LSUSB
Yeah, still need lsusb! As @etorix points out, there’s really no risk or impact to system stability or performance. I notice he didn’t mark as accepted like the jailmaker request.
Could be why 
Mis and Disinformation.
PS how much does lsusb actually add?
No more than 500 KiB, fully installed. (For the entire “usbutils” package.)
3 Likes
usbreset is part of that package also. Along with usb-devices and usbhid-dump. usbreset can be handy at times too.
Just came here trying to identify a USB device to pass through to a docker container. Seems crazy to be leaving out lsusb. Still missing in latest beta of scale (Electric Eel). Hopefully it get’s added - no idea why it wouldn’t be already, it seems like a crucial part of any system to me.
Edit well I found another way of doing it for others that come here.
ls -l /dev/serial/by-id take the device name off the end probably ttyUSB0
then in your docker container
-v /dev/ttyUSB0:/dev/ttyUSB0 \
All done.
Worked for me anyway.
For lsusb, you can just grab the lsusb binary from a Debian 12 machine/vm and upload it to your Truenas system. I’d put it in a home directory instead of /usr/bin. Make sure to chmod u+x the binary.
Or you can grab the lsusb.py from the linux-usb GitHub repo (github (dot) com/gregkh/usbutils/tree/master). Copy it to your TrueNAS system. chmod u+x the .py file and run it. Doesn’t give as much info as the lsusb binary, but it does the job
Discouraged may be true, but so what? There’s a big difference between saying a configuration won’t be supported directly by iXsystems and saying that the OS distribution is deliberately crippled to prevent people from doing useful things with their hardware without resorting to package management—which is explicitly unsupported and gets blown away by the middleware on upgrades, making that a worse option than just including the diagnotics in the first place.
I get that a lot of people on the forums are FreeBSD people, but on Linux the Linux Standards Base including lsusb is supported by the Linux Foundation, is available on all mainstream distros, and is even included in minimal OCI images like Alpine Linux.
# if you can't rely on PATH use /usr/bin/lsusb
docker run -t --rm alpine:latest "lsusb"
Standards are standards for a reason. There is no legitimate reason to exclude basic diagnostic and system utilities from the TrueNAS Linux distribution except for tools which break its middleware. Even then, I’d rather see standard utilities included and marked as “use at your own risk” than see the TrueNAS distro experience be crippled out of the box or fail to meet basic standards like the LSB or Filesystem Heirarchy Standard (currently FHS 3.0).
I’m voting to have the entire LSB suite included because it’s a standard. Perhaps someone who knows more about iXsystem’s distro PR policy for TrueNAS Scale will make a pull request for it since it’s likely to be a one-line diff.
2 Likes
Nice rant. Doesn’t have anything to do with the post you’re replying to, though. Neither I nor anyone else in this thread are saying these utilities shouldn’t be included.
I’ve voted for you request, and responded to the inevitable rebuttals. Meanwhile, assuming you’ve enabled application support via Docker for TrueNAS scale and had your SSH-enabled user added to the docker group, the following is insecure but useful in a pinch:
docker run --privileged -it --rm alpine:latest "lsusb"
If you need the output from lsusb as a tree, or need the detailed info from usb-devices then you’ll have to install the usb-utils package first. For example:
# open a shell in an ephemeral container
docker run --privileged -it --rm alpine:latest
# add usbutils
apk update && apk add usbutils
# tree output from lsusb
lsusb -t
# get more detailed output about devices
usb-devices
# detach from the container; docker will
# automatically stop and delete remove
# the modified container because `--rm`
exit
This works for me on TrueNAS Scale 24.10, and I tested it on TrueNAS-SCALE-24.10.0.2 without any issues. YMMV on versions before Electric Eel.
If you’re familiar with Docker, the /proc and /sys filesystems, and Linux capabilities, then you can and should be able to make it more secure by restricting the container’s access to just the bind mounts and capabilities you actually need. That said, Alpine is a highly-respected distro with a good security track record, and one assumes that you’d be running this as a user that could gain root anyway, so the privileged approach just seems easier and more immediately useful.
NB: For the peanut gallery just waiting to argue “but security!”, it should be noted that a number of apps currently distributed through the stable and community trains don’t restrict privileges much if at all. Anyone wanting to make hay over “container security” for a privileged user should probably tilt at that windmill instead. Highly-privileged commands are user friendly; they’re just choosy about who their friends are!
2 Likes
Yep, agree and am aware but my request was really for everyone else and convenience. It should be there indeed. Thanks for the vote!
1 Like
Just voted for this, as well. Aside from the other use cases mentioned here, I’d argue that it does have implications for storage.
I recently needed to transfer some data onto my TrueNAS’ main pool from a SATA disk in a USB enclosure. Given the constraints of my setup, I couldn’t shuck the disk and put it directly on my SATA bus, and didn’t think anything of just mounting the disk and using rsync to copy the data. This was, for reference, nearly 2 TB of data.
Transfer speeds were atrocious (30 MB/s max), and I knew the USB enclosure and the SATA disk were working fine due to recently using them on another system.
I tried to use lsusb to check the speed the enclosure was connected at, but of course it’s not there. Eventually, I figured out the problem (the USB port was downgraded to USB 2.0 speeds). But it took me over an hour of troubleshooting instead of the 5 seconds it would have taken me if I’d had the full set of standard diagnostic tools. I also had the added stress of not being able to easily rule out that my not-cheap disk or enclosure were failing.
The transfer finished (slowly) without any errors, but took ~2 hours instead of the minutes it should have taken. Since I didn’t have the diagnostic tool I expected to have, and it was working (slowly), I didn’t want to interrupt it in case something deeper was wrong.
2 Likes
Hi,
You stated that “the USB port was downgraded to USB 2.0 speeds” which seems exactly like the problem I’m experiencing (I opened a thread here
How were you able to fix it? Did you have to install something to get USB 3 working?
Thanks
My message was phrased badly.
The ports on this server’s case are not labeled. I didn’t realize it, but I was plugged into a USB 2.0 port. I didn’t even realize there were that many USB 2.0 ports on the board.
Having lsusb available would have let me see the link speed was 480M immediately, which would have saved me a substantial amount of troubleshooting.
2 Likes
I would like to see all ls* commands since this could be needed for a variety of things, but my specific use is to locate my PCIe Coral TPU for my Frigate. USB seems to work automatically, but mine is a PCIe. I need the device name to add it which we can do with docker and Truenas Scale 24.10, but I need the /dev name for it.
This thread really needs a specific list of what commands are considered ‘missing’ from the current versions of TrueNAS Scale and the upcoming Fangtooth.
What is currently included by default and what is desired?
1 Like