Description of problem: After abrt crash, I'm unable to report it because backtrace generation fails due to permission problem while unpacking debuginfos. Version-Release number of selected component (if applicable): abrt-addon-ccpp-2.14.4-5.fc33.x86_64 How reproducible: always Steps to Reproduce: 1. have something crashed 2. use abrt gui to report the problem 3. try to generate backtrace locally Actual results: Stahování (1 z 30) libreport-web-debuginfo-2.14.0-8.fc33.x86_64.rpm: 100% Extrahování cpio z /var/tmp/dnf-kvolny-vklbmgiz/updates-testing-debuginfo-a0500649f598dc92/packages/libreport-web-debuginfo-2.14.0-8.fc33.x86_64.rpm Kešování souboru z unpacked.cpio vytvořeného z libreport-web-debuginfo-2.14.0-8.fc33.x86_64.rpm Nelze rozbalit soubory z '/var/tmp/abrt-tmp-debuginfo.pmXxfn/unpacked.cpio'. Pro více informací viz '/tmp/abrt-unpacking-58vzkyky' Rozbalování selhalo, ruším stahování... Can't download debuginfos: [Errno 1] Operace není povolena: '/var/cache/abrt-di/usr' Expected results: (no such error, I can finish reporting to bugzilla) Additional info: $ cat /tmp/abrt-unpacking-58vzkyky cpio: ./usr/lib/debug: Cannot change mode to rwxr-xr-x: Operace není povolena cpio: ./usr/lib/debug/.build-id: Cannot change mode to rwxr-xr-x: Operace není povolena cpio: ./usr/lib/debug/.build-id/e2: Cannot change mode to rwxr-xr-x: Operace není povolena cpio: ./usr/lib/debug/usr: Cannot change mode to rwxr-xr-x: Operace není povolena cpio: ./usr/lib/debug/usr/lib64: Cannot change mode to rwxr-xr-x: Operace není povolena 338 blocks "Operace není povolena" = "Operation not permitted"
Can you post: ls -l /var/cache/abrt-di/usr ls -l /var/cache/abrt-di ls -ld /var/cache/abrt-di
[root@kvolny ~]# ls -l /var/cache/abrt-di/usr total 8 drwxrwxr-x. 3 abrt abrt 4096 Feb 25 2019 lib drwxrwxr-x. 3 abrt abrt 4096 Feb 25 2019 src [root@kvolny ~]# ls -l /var/cache/abrt-di total 4 drwxrwxr-x. 4 abrt abrt 4096 Feb 25 2019 usr [root@kvolny ~]# ls -ld /var/cache/abrt-di drwxrwxr-x. 3 abrt abrt 4096 Sep 24 10:20 /var/cache/abrt-di
This is left over of https://bugzilla.redhat.com/show_bug.cgi?id=1796245 and commit cc79333dcd3fea7701ebbf97fb0919fbad90f3f0 The solution should be either chmod -R g+w /var/cache/abrt-di or rm -rf /var/cache/abrt-di/* We should add it to post scriptlet to easy migration.
I still have the same issue: $ LC_ALL=C ls -al /var/cache/abrt-di total 0 drwxrwxr-x. 1 abrt abrt 46 Nov 1 12:36 . drwxr-xr-x. 1 root root 198 Nov 1 13:04 .. -rw-r--r--. 1 root root 0 Nov 1 12:36 .migration-group-add drwxrwxr-x. 1 abrt abrt 6 Oct 24 09:18 usr (In reply to Miroslav Suchý from comment #3) > This is left over of https://bugzilla.redhat.com/show_bug.cgi?id=1796245 and > commit cc79333dcd3fea7701ebbf97fb0919fbad90f3f0 > The solution should be either > chmod -R g+w /var/cache/abrt-di > or > rm -rf /var/cache/abrt-di/* These workarounds solve the issue for me, thanks!
*** Bug 1901455 has been marked as a duplicate of this bug. ***
Running rm -rf /var/cache/abrt-di/* helped. Didn't you add the post scriptlet as you mentioned above? I update my system regularly so I am confused why I still need the workaround four months after the fix was discovered. Anyway, thank you for the workaround!
It prevents me from sending abrt reports for fedora 34.
I can see the chmod command from the workaround in the post scriptlet. If the problem still persists in f34, can you send the output of: ls -l /var/cache/abrt-di/usr ls -l /var/cache/abrt-di ls -ld /var/cache/abrt-di To see if we still see the same issue or if it is something else.
After the rm -rf mentionned earlier, abrt worked fine. Nonetheless, here the output you asked for: fred@grey-matter ~ ls -l /var/cache/abrt-di/usr total 8 drwxrwxr-x. 3 fred abrt 4096 22 mars 14:27 lib drwxrwxr-x. 3 fred abrt 4096 22 mars 14:27 src fred@grey-matter ~ ls -l /var/cache/abrt-di total 4 drwxrwxr-x. 4 fred abrt 4096 22 mars 14:27 usr fred@grey-matter ~ ls -ld /var/cache/abrt-di drwxrwxr-x. 3 abrt abrt 4096 22 mars 14:27 /var/cache/abrt-di
(In reply to fred from comment #9) > After the rm -rf mentionned earlier, abrt worked fine. Nonetheless, here the > output you asked for: > > fred@grey-matter ~ ls -l /var/cache/abrt-di/usr > total 8 > drwxrwxr-x. 3 fred abrt 4096 22 mars 14:27 lib > drwxrwxr-x. 3 fred abrt 4096 22 mars 14:27 src > fred@grey-matter ~ ls -l /var/cache/abrt-di > total 4 > drwxrwxr-x. 4 fred abrt 4096 22 mars 14:27 usr > fred@grey-matter ~ ls -ld /var/cache/abrt-di > > drwxrwxr-x. 3 abrt abrt 4096 22 mars 14:27 /var/cache/abrt-di Thanks for the data. This is after you already did the workaround right? Because this looks ok. I was wondering what the output looked like before the workaround was done, but I guess that is not possible to provide unless you hit the issue again on another machine, which is probably not going to happen.
Potential duplicate: bug 1912843.
I might be encountering the same issue. Here is the output for me. I did not do the deletions (or it must have been a while ago, and I forgot): $ ls -l /var/cache/abrt-di/usr total 0 drwxrwxr-x. 1 abrt abrt 10 Apr 29 2020 lib drwxrwxr-x. 1 abrt abrt 10 Apr 29 2020 src $ ls -l /var/cache/abrt-di total 0 drwxrwxr-x. 1 abrt abrt 12 Apr 29 2020 usr $ ls -ld /var/cache/abrt-di drwxrwxr-x. 1 abrt abrt 46 Jan 26 01:26 /var/cache/abrt-di
I confirm that the following fixed this issue also for me: # rm -rf /var/cache/abrt-di/* After deleting and reporting four crashes that could not be reporter before, I have now these directory permissions: # ls -l /var/cache/abrt-di/usr total 4 drwxrwxr-x. 3 jan abrt 4096 May 2 13:02 lib # ls -l /var/cache/abrt-di total 4 drwxrwxr-x. 3 jan abrt 4096 May 2 13:02 usr # ls -ld /var/cache/abrt-di drwxrwxr-x. 3 abrt abrt 4096 May 2 13:02 /var/cache/abrt-di
*** Bug 1912843 has been marked as a duplicate of this bug. ***
Created attachment 1778722 [details] file list of the problematic abrt-di directory I attached a list with the files in /var/cache/abrt-di of a system that suffers from this bug. Note that some files have only read permissions. Example: -r--r--r--. 1 jan abrt 18584 Feb 20 11:33 python3.9-3.9.1-2.fc33.x86_64.debug Also note that most files are owned by user abrt, but some of them by user jan. It seems that they are all in group abrt.
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.