Tails

#2 Updated by segfault 2018-07-31 09:18:59

I was not able to reproduce this issue - it does not happen with the file containers and the USB stick I use for testing.

#7 Updated by intrigeri 2018-09-05 08:17:27

If you don’t manage to gather enough debugging info to understand (and ideally, fix) this bug, perhaps the best we can do is to document the workaround.

#9 Updated by intrigeri 2018-10-31 15:56:07

intrigeri wrote:
> If you don’t manage to gather enough debugging info to understand (and ideally, fix) this bug, perhaps the best we can do is to document the workaround.

Let’s decide something, please :)

#10 Updated by intrigeri 2018-11-06 12:29:20

1. ask reporters to reproduce on 3.10.1
2. try to reproduce with a non-removable USB stick

If none of these bring us a reproducer, close.

#13 Updated by segfault 2018-11-06 15:05:53

> ask reporters to reproduce on 3.10.1

I sent an email to the three reporters listed in the description and asked them to reproduce this on 3.10.1.

#14 Updated by intrigeri 2018-11-07 10:39:13

> I was not able to reproduce with a non-removable USB stick. But I noticed something else (or actually, remembered something I had already noticed, but forgot to document): The user will get prompted for an admin password if they try to mount a volume for which the timeout exceeded during unlocking (see Bug #15733). When this happens, udisks does not store the UID which unlocked the volume, so it doesn’t know that the user is allowed to mount it.

OK, good to know!

> I sent an email to the three reporters listed in the description and asked them to reproduce this on 3.10.1.

Great. Let’s close as resolved unless there are new failure reports or these folks report they can reproduce on 3.10.1 by Nov 18.

#16 Updated by segfault 2018-11-25 22:43:06

segfault wrote:
> I sent an email to the three reporters listed in the description and asked them to reproduce this on 3.10.1.

So far, two of the three reporters replied to my request: One can still reproduce their issue with 3.10.1, the other one can’t. I got a whisperback report from the first one, I will see if I can figure out their problem from the logs.

#17 Updated by segfault 2018-12-15 12:27:05

segfault wrote:
> So far, two of the three reporters replied to my request: One can still reproduce their issue with 3.10.1, the other one can’t. I got a whisperback report from the first one, I will see if I can figure out their problem from the logs.

The whisperback report showed that the user didn’t actually try any of the supported ways to unlock a VeraCrypt volume, but used the VeraCrypt application. They didn’t reply back to my request to try it with a supported method.

So of all the users who reported issues with volumes requiring an admin password (it were actually four, not three) one tried it again in 3.10.1 and didn’t encounter the issue anymore.