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.
Food for thought: This is still an issue on f43 and f44 when 7z is invoked as root since /usr/sbin/ is listed before /usr/bin in $PATH for the root user. This causes issues for ansible modules leveraging 7z (e.g. community.general.iso_extract [1]) since these quite often run as root on the managed nodes. Ansible will resolve the full path to the binary [2] and invoke the first valid one, i.e. /usr/sbin/7z in this case. This in turn leads to Codec Load Error: /usr/sbin/7z.so : errno=2 : No such file or directory as described above. [1] https://docs.ansible.com/projects/ansible/latest/collections/community/general/iso_extract_module.html [2] https://github.com/ansible/ansible/blob/1d398ae8af25132dc5290226517a7c8763ae295b/lib/ansible/module_utils/basic.py#L1387-L1405
7z also fails to run when invoked as /usr/sbin/7z which affects the root user whose $PATH has /usr/sbin before /usr/bin. I've already proposed a fix for mc (Midnight Commander) but it would be nice to fix it 7-zip instead. Does this package have a maintainer? I see a dozen of open bug reports, and multiple CVEs.
FEDORA-2026-4be7569210 (7zip-26.01-1.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-4be7569210
FEDORA-2026-f36864b408 (7zip-26.01-1.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-f36864b408
FEDORA-EPEL-2026-8d909527ba (7zip-26.01-1.el10_2) has been submitted as an update to Fedora EPEL 10.2. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2026-8d909527ba
FEDORA-EPEL-2026-52d18d8d5a (7zip-26.01-1.el10_3) has been submitted as an update to Fedora EPEL 10.3. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2026-52d18d8d5a
Unfortunately the latest update does not entirely fix this issue: # cat /etc/fedora-release Fedora release 45 (Rawhide) # /usr/sbin/7z x /var/tmp/test.iso 7-Zip 26.01 (x64) : Copyright (c) 1999-2026 Igor Pavlov : 2026-04-27 64-bit locale=C.UTF-8 Threads:16 OPEN_MAX:524288 Codec Load Error: /usr/sbin/7z.so : errno=2 : No such file or directory Scanning the drive for archives: 1 file, 374784 bytes (366 KiB) Extracting archive: /var/tmp/test.iso ERROR: /var/tmp/test.iso Cannot open the file as archive Can't open as archive: 1 Files: 0 Size: 0 Compressed: 0 Looking at https://src.fedoraproject.org/rpms/7zip/blob/0557591d53bbfa4ec3c73728b31f101158afc3c7/f/7zip-find-so-in-libexec.diff it seems /bin/7z and /usr/bin/7z are fixed, but /usr/sbin/7z is still not addressed.
I've already tried to fix this in Midnight Commander but its developers are not particularly excited: https://github.com/MidnightCommander/mc/pull/5125
FEDORA-EPEL-2026-52d18d8d5a (7zip-26.01-1.el10_3) has been pushed to the Fedora EPEL 10.3 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2026-8d909527ba (7zip-26.01-1.el10_2) has been pushed to the Fedora EPEL 10.2 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-4be7569210 (7zip-26.01-1.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-f36864b408 (7zip-26.01-1.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
26.01-1.fc44 from testing does NOT fix the issue.