Thank you, and welcome. Good practice for another time, when you run into something harder.

You mention /usr/lib/mozilla/plugins/flash-mozilla.so twice already, so if I mention it once more, it'll sure be the right place

I'm not too well versed in this, but I might be able to help.

Firstly, I think that your /etc/udev/rules.d/10-scanner.rules should have a single rule line. It should be read "if the vendor is 0x04f9 and the product is 0x0330, then make the /dev/whatever pathname have group scanner". All that needs to be on a single line.

What you have done is rather three independent statements: "if the vendor is 0x04f9, then eeh nothing", "if the product is 0x0330, then ehh nothing", "if whatever, then set /dev/whatever to have group scanner". That last one in particular is quite "destructive" (although there might be some kind of protection in udev for that kind of mistake).

But, when I look at the libsane rules (i.e., /lib/udev/rules.d/60-libsane.rules) it suggests that you should rather have the assignment

..., ENV{libsane_matched}="yes"

as effect instead of setting access group. I think the deal is that the scanner dev's (for whatever [expletive] reason) have decided to use "acl" rather than unix file protection, and they also have programmed their rules to use a common, actual effect via the setting of the libsane_matched variable.

So, if making it a single line doesn't work, you might try replacing the GROUP assignment with that assignment.

EDIT: note the comma (",") between the terms; i.e., when you join your lines, you need to add "," comma between them.

If I may suggest a couple of "improvements" within that scheme, to in particular simplify the picture for the helpee.

Firstly that you set up key based authentication for helpee, to ssh to you without password.

Secondly that you set up ~/.ssh/config for helpee with a short logical hostname to your host. In that you would also reverse forward to both ports 22 and 5900 in the single ssh link. E.g. like the following stanza

Host help
   hostname ...
   user ...
   identityfile ...
   remoteforward 7000 localhost:22
   remoteforward 5901 localhost:5900

Thirdly a script for the helpee to run the two things as one:

ssh help & x11vnc

With the second forwarding, you, the helper, would only need to run vinagre against localhost:5901, or indeed xvnc4viewer against :1, and also have the ssh back link on localhost:7000.

I suppose x11vnc accessed with xvnc4viewer via ssh is too old-fashioned?

What does that mean? afaik sshfs is just a mounted (remote) file system for the client??
In fact as recent as last week, I used it with my mplayer on the client.

Also, you should check permissions on /dev/bus/usb/001/00[56]
If udev doesn't recognize their vendor/product id, it'll just set up "generic" nodes, which probably are not accessible by a user.

The original poster does that by editing the "subject" line of the first post. You can try it out on this topic, if you think this answered your question.

Yeah. By the looks of it, it's all set up perfectly fine, and renewal should have happened nicely and smoothly already last month. It didn't. As the "certbot" is something opaque in too many lines of python, it's become a matter of tracing it more tightly for the next time...

I'm not sure what that "obscure" scripting attempts to do, but you really only need the following script as /etc/acpi/lid.sh:

#!/bin/bash

if [  "$3" = "close" ] ; then
     /usr/sbin/pm-suspend
fi

The program pm-suspend is from the pm-utils package.

Of course, if you want screen lock, the script needs some more, and it depends of which screen locking you are using.

You may note that everything previously ascribed to the old user id is now ascribed to the new user id, except where it occurs within posts (unless the poser used the "user" markup).

Cheers.