Crash on Ubuntu 22.04 with a PDF #620
Comments
|
I've tried with other documents too, and with the CLI application - the result is the same, it never works! |
|
Thanks for reporting this. Just to be clear, you're trying to run Dangerzone from the source code, correct? (I see some [DEBUG] messages that seem to indicate that). If that's the case and you wish to install Dangerzone as a regular user, which should work, then the instructions are available here. We can't always guarantee the latest development version will work out of the box as we haven't done the extensive quality assurance (QA) procedures as we do with our releases. Regardless, I can help you address said issue in the development version. |
|
No, I have just installed the debian package: |
|
OK. That's a bit more concerning. And thanks for reporting. I'll look into it. |
|
@j75 The "Permission denied" errors may hint at SELinux/AppArmor being enforced in your system. In particular, rootless containers may not work properly with AppArmor, if I read this issue correctly: containers/podman#19303 So, can you please run the following commands to find out if AppArmor/SELinux is enabled in your system? |
|
|
|
OTOH |
|
Ok, next question would be: if you try to run Dangerzone with AppArmor disabled, does it complete successfully? This way, we can narrow it down to just that.
Actually, a |
@j75 the same logic applies to
Basically |
I performed (as root) |
|
Thanks a lot for trying it out. Bummer that we still don't know the root cause. So, we have a permission denied error at our hands, which manifests even with AppArmor / SELinux in non-enforcing mode. We're missing something here, and we need an Ubuntu environment to properly test it out. Until we have such an environment, I have one more thing to ask. Can you:
Thanks again for the help 🙂 |
|
Here is the journal (I stopped the apparmor service before starting dangerzone):
|
|
Thanks for pasting that in (RIP pamela 😢 ). Unfortunately, it appears that no warning appeared there before the issue, so we'll have to dig deeper in an fully ubuntu install of our own to try and reproduce this. One detail that I noticed though is that this time it failed on page 3 instead of 9. So, at some arbitrary point the directory to which the isolated environment is trying to use becomes unwritable. So I wonder if this is time-related or space related. So if you're up for helping tracking this down a little more, I have one more request for you: let's check if this is a space limitation on your system. On a terminal, if you type for the line about |
j75
changed the title
|
df -k => Runing dangerzone and watch only show a modest increase in /dev/shm and /tmp (55 M and 13 M). |
|
Thanks for checking. Another dead-end. It's not a space issue either. |
|
I tested the CLI version ( |
|
Now I'm trying dangerzone on another computer (a laptop) and the messages are different: However the graphical applications still asks me to supply a document - normally it shouldn't because the podman image is not installed... but that's another issue... |
I'd say this is a different issue. Likely caused by an almost full disk. We can discuss that further here: #193 (comment) |
|
Strange... I have over 100G free in my /home partition, and normally |
|
Just installed Ubuntu 22.04 and ran Dangerzone successfully on a 66 page document and a 4 page one without running into issues. So unfortunately I was unable to reproduce this issue. Without it I don't know what else I can use to find out what the root cause could be. |
|
Sigh, how did I miss it: This command tells us two things:
I'd check the following next:
@deeplow Can you check it as well in your Ubuntu 22.04 environment? |
|
Yes, my user id is 1602 hence that value. And my "temp" variables are I am the owner of the |
|
I tried I presume that /tmp/dangerzone is in the podman's container. |
|
However, as far as I understand the error messages are in the |
|
My |
I did so and it worked. By default it used |
|
what about using another user id (different from 1000)? |
|
I managed to reproduce the problem by running a simple script that executes |
|
Hey @j75, sorry for the delay. I see you've made a lot of progress in this issue, nice! So, we have a workaround, but it has questionable security implications. First of all, I'll reply on your comments to clarify some things, and then I'll suggest some next steps:
Great, thanks for the info. In theory, the fact that this directory is owned by you should still make Dangerzone work.
Ok, let's shelf the "out of space" theory then.
Kind of. The error messages do come from Podman, but the problem is the mounted directory in the container, which is part of the host. But we'll see it later on.
Bingo, that's the problem. Here's the thing, if you check the Podman invocation, there's a So what's the issue here? The So, where are we going from here now? Unfortunately, this is something that needs to be solved at the Dangerzone level. This can be solved as a side effect of fixing #443. This will require some redesign in the application, so it may take a while to land. In the meantime you can use the |
|
|
|
Oh I'm sorry, I should probably elaborate. The workaround is to let Dangerzone create world-writeable directories ( For proof-of-concept reasons, you can use the following script: #!/bin/bash
ORIG_UMASK=$(umask)
ORIG_TMPDIR=$TMPDIR
umask 0077
export TMPDIR=$(mktemp -d)
umask 0000
echo "Dangerzone will create world-writable dirs in $TMPDIR"
dangerzone
rm -rf $TMPDIR
umask $ORIG_UMASK
export TMPDIR=$ORIG_TMPDIRIt will basically create a directory that is only accessible by your user ( I should stress again that this is a hacky script, so please don't use it for anything other than evaluating Dangerzone 🙂 |
|
Yes, your script solves my problem (and I used sh not bash as the first is POSIX compatible, if I'm not wrong). A small remark (should it be another issue?): the original document (https://s1.q4cdn.com/806093406/files/doc_downloads/test.pdf) has |
Good to hear!
I had just come across that myself independently not even 20 minutes ago (what a coincidence). I opened the issue #626 to address it, |
|
I have just started trying to use Dangerzone and I think I'm running into this problem as well. My system is Ubuntu Budgie 22.04.4, podman 3.4.4 is installed, and all my storage is ZFS. When running as an unprivileged user it reports:
Full messages here: https://gist.github.com/nealrauhauser/142cee89d9615152820f78dbc73c5e8b If I run dangerzone-cli as root the error report offers much less context.
https://gist.github.com/nealrauhauser/e8a3648459393766ee42007c1463cd9d I have a laptop that's using ext4 and I get similar failures. I'm willing to put some time into resolving this, but could really use some hints on where to start. |
|
The issue you're encountering seems to be that rootless Podman (which is the underlying container runtime that Dangerzone uses on Linux) cannot run on ZFS. I don't have a ZFS system, unfortunately, but there are several articles on the internet that offer some solutions for the issue (e.g., https://blog.dest-unreach.be/2024/01/03/podman-on-zfs/). I was about to move the above comment to a separate issue ("Cannot run Dangerzone on ZFS systems"), but then that line threw me off:
If you can give us some logs from that system, it would help. |
|
I believe the main issue in this discussion, as well as some other ones that have been reported, is now fixed, as of #625. Let us know if you encounter similar problems with the upcoming 0.8.0 release. |
Hello,
Running the application on Ubuntu 22.04 does not work, the error messages are
The text was updated successfully, but these errors were encountered: