You people ARE treating TrueNAS like it is a desktop. I don’t know how else to stress how idiotic this request is (or how stupid it is for 7z to be included in CORE). More unnecessary packages will only result in more security issues. Please explain why if libarchive is already being maintained then why would you add something else for the same results?! One tool, not two!
Debian:
https://manpages.debian.org/bookworm/libarchive-tools/bsdtar.1.en.html
bsdtar -tf <filename.rar>
So true. I have yet to find any NAS that supports VMs, “Apps”, or creating custom jails to run different types of software.
The only thing a NAS does these days is just sit there and serve files. Nothing else.
“The only thing *John’s (or most enterprise’s too) True*NAS *CORE* does these days is just sit there and serve files. Nothing else.”
Fixed that for you.
So if you already have the ability–with base tools–to (un)zip, (un)7zip, (un)gzip, and probably half a dozen more formats then why do you need another tool? …And if you do add another (unnecessary-maintained-somewhere-else) tool like what someone did in this thread you should do it in a jail of some sort (because this is probably for data you did not create yourself)!
man 3 libarchive
So let’s talk about minio and why it has a dependency on some other tool. What is minio and why do I need it on my TrueNAS?
So we already can test, extract, and create 7z and RAR archives with TrueNAS SCALE? That’s great news! 
Without relying on a jail or VM, and without downloading any binaries, can someone paste in here how they do that on TrueNAS SCALE?
If we can already handle 7z and RAR (including recent versions, multivolume, and password-protected), then that means we’re all good to go. 
scroll in an upwards direction.
On Arch Linux, which follows upstream more closely than Debian (which has a “package version freeze” policy for each release iteration):
file myArchive.rar
myArchive.rar: RAR archive data, v4, os: Win32
bsdtar --version
bsdtar 3.7.4 - libarchive 3.7.4 zlib/1.3.1 liblzma/5.6.1 bz2lib/1.0.8 liblz4/1.9.4 libzstd/1.5.5
bsdtar -xf myArchive.rar
File CRC error: Invalid or incomplete multibyte or wide character
bsdtar: Error exit delayed from previous errors.
7-Zip 24.08 (x64) : Copyright (c) 1999-2024 Igor Pavlov : 2024-08-11
7z x myArchive.rar
Everything is Ok
Folders: 1
Files: 10
Size: 1041155
Compressed: 127854
For multivolume, password-protected, and recently created archives (e.g, WinRAR 7), 7-zip is superior to libarchive. (In fact, it’s mandatory in some cases.)
I don’t have access to your computer so you’ll have to RTFM yourself but I suspect RAR Ver 4 is the problem for you.
libarchive(3)
My FreeBSD 14.1 says:
“RAR and most RAR5 archives,”
My MacBook says:
“RAR archives,”
Debian man page (on the internet) says:
“RAR and most RAR5 archives,”
To listen to MP3s mplayer is…
Again, it’s a NAS not a desktop.
…
People, chill…
As I said way back in comment 18 this is a perfectly valid feature request. It is not that deep.
Patrick is correct. There is some legitimate value in being able to do some basic file manipulation directly on the NAS. Compress / decompression makes sense in some scenarios to have available in the base system.
Additionally with docker support, there is a lot of value in being able to run one-liner shell commands to run arbitrary images that manipulate files on-disk as well. Thinking of the case to use tools like ffmpeg or imagemagik to do media conversion and manipulation tasks directly on the storage array.
And what I’m saying is that should be the responsibility of the container. Think “method” in programming.
Then, can you please accept this feature request? 
So the question is where is the line? Which file types and operations do you support in base? Do you only offer “support” for archives but not MP3s or PNGs and what extra overhead are you willing to incur.
Copying, moving, renaming, extracting, compressing, etc. It’s not that extreme.
I don’t know why you’re trying to conflate multimedia encoding, graphics editing, and audio streaming with the basic usage of extracting archive files.
It’s for the same reason it makes sense to have checksum tools immediately available on the server itself, without the need to rely on a container or VM, nor have to transfer the file over the local network just to run a checksum.
There’s a difference between FFmpeg and sha256sum. There’s a difference between MPlayer and 7z.
Man, I’m not sure why you have to be so argumentative about everything… Do I need to put you in time-out? That is the whole reason for the request, and we are evaluating if the impact is minimal enough to warrant including it. A few MB here or there to enable some storage relevant operations isn’t the end of the world. Chill.
+1 for me.
For me my use case is i store VM images/backups on truenas and these can be in excess of 100GB. Having them in a ZIP file usually halfs that if not more but having to move the backups to my PC to zip the backup is time consuming and sometime more work than its worth as i have to try to make space to fix the backup and the compressed backup.
I want to be able to copy the backup to truenas and compress it there. Doing it with a container if fine but just slow the whole process down.
As a side note, why zipping them? Place them in a dataset with high compression and ZFS keeps care of the file integrity.
Or does WinRAR compress them more that ZFS can do?