See bug originally reported at KDE - https://bugs.kde.org/show_bug.cgi?id=505637 When attempting to create or extract .7z files using KDE Ark on Fedora, the operation fails with the following error: "ark.cli7z: Load Error: /usr/bin/7z.so : errno=25 : Inappropriate ioctl for device" This issue is caused by how Fedora packages the 7-Zip backend. Fedora patches the 7-Zip source to expect the 7z.so module in /usr/libexec/7zip/, but it installs the 7z binary in /usr/bin and the 7z.so file in /usr/libexec/7zip/. However, Ark (or its CLI backend wrapper) attempts to load 7z.so from the same directory as the binary (/usr/bin/7z), which causes it to fail. Other distros like Arch Linux do not patch the 7-Zip source, instead: 1-Install 7-Zip under /usr/lib/7zip/ (where both the binary and .so are placed), 2- Place wrapper scripts in /usr/bin/ to call the correct locations. 3- As a temporary workaround, copying 7z.so into /usr/bin/ resolves the issue, indicating a path mismatch as the root cause. Reproducible: Always Steps to Reproduce: 1. Have Ark and 7-zip installed on Fedora. 2. Attempt to extract or create a .7z archive using Ark. 3. Observe the error in the terminal or logs. Actual Results: Unable to extract or create .7z files in Ark. Expected Results: Successfully extract or create .7z files in Ark.
CC: Fedora 7zip package maintainer
It looks like a regression in 7zip, as ark worked fine before switching from p7zip to 7zip. Reassigned it to 7zip
I just ran into this while working on patool and had an interesting observation. The error only occurs when `7z` is invoked using the full path. Compare `7z i` vs. `/usr/bin/7z i`. The first will print information regarding formats and codecs, etc. It also states: Libs: 0 : 24.09 : /usr/libexec/7zip/7z.so The latter bails out with: Codec Load Error: /usr/bin/7z.so : errno=2 : No such file or directory Apparently, when the full path is given, `7z` expects the library to be present in the same location as the executable. It looks like the applied patch [1] does not work when using the full path to the executable. Since 7zip is replacing p7zip in F43+, this should be fixed before F43 is shipped. [1] https://src.fedoraproject.org/rpms/7zip/blob/rawhide/f/7zip-find-so-in-libexec.diff
> Apparently, when the full path is given, `7z` expects the library to be > present in the same location as the executable. It looks like the applied > patch [1] does not work when using the full path to the executable. > > Since 7zip is replacing p7zip in F43+, this should be fixed before F43 is > shipped. > > [1] > https://src.fedoraproject.org/rpms/7zip/blob/rawhide/f/7zip-find-so-in- > libexec.diff I have amended the patch so the library will always be searched for in /usr/libexec/7zip: https://src.fedoraproject.org/rpms/7zip/pull-request/5
Ping? Could one of the maintainers please merge the PR and rebuild or state what's keeping the fix from being shipped?
I also bumped into this when trying to build the Julia package.
FEDORA-2025-e3ef218150 (7zip-24.09-6.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-e3ef218150
Proposed as a Freeze Exception for 43-final by Fedora user ngompa using the blocker tracking app because: 7zip (which is included on media) is broken OOTB without this.
The patch is not compatible with flatpak builds (e.g. for ark) which use the /app prefix instead of /usr.
Discussed at the blocker review meeting on 20th Oct. 2025 AGREED AcceptedFinalBlocker This is upgraded and accepted as a Final BLOCKER as a violation of Final criterion "For all release-blocking desktop / arch combinations, the following applications must start successfully and withstand a basic functionality test: ... archive manager", as testing indicates this affects all standard ways of interacting with archives in KDE (ark, Dolphin) and 7zip archives are very common, especially for platform-agnostic interchange. https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2025-10-20/f43-blocker-review.2025-10-20-16.02.html
FEDORA-2025-e3ef218150 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-e3ef218150` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-e3ef218150 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Fedora Update System from comment #11) > FEDORA-2025-e3ef218150 has been pushed to the Fedora 43 testing repository. Fixes both Ark and Dolphin
Unfortunately this isn't enough to fix my use case in the Julia package. Julia calls 7z via a symlink /usr/libexec/julia/7z which points to /usr/bin/7z. This ensures Julia uses /usr/bin/7z even if PATH has been changed by the user. But that fails because the symlink doesn't start with /usr/bin. I can work around this in several ways, but it's annoying that symlinks don't work.
Ugh, yes, we definitely want that usecase to work. Let's keep this bug open for now.
FEDORA-2025-e3ef218150 (7zip-24.09-6.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
Maybe the Julia case should be a separate bug?
anyway, f43 is out, so dropping blocker metadata.