Debian 8 (jessie) stores Grub 2 password parameters within the directory /etc/grub.d/ . Inside this directory there are only scripts used to generate the configuration file.
So you can create a new script (e.g. /etc/grub.d/01_users ) with the following content:
#!/bin/bash
cat <<EOF
set superusers="putyourusernamehere"
password putyourusernamehere grub.pbkdf2 grub.pbkdf2.sha512.10000.3450C89...
EOF
All the above lines are part of the file, because it is a script whose output will go in the final configuration file. Since it is a script, it will only be processed if it is executable (chmod a+x ...).
As an alternative, you may put just the lines you need in one of the existing files that are tweaked to output their own contents. Here you can see how /etc/grub.d/40_custom substitutes the shell with a tail command returning script contents starting from the third line:
#!/bin/sh
exec tail -n +3 $0
set superusers="putyourusernamehere"
password putyourusernamehere grub.pbkdf2 grub.pbkdf2.sha512.10000.3450C89...
In some Ubuntu derivatives (e.g. Mint 19) the format of the password changed as follows:
#!/bin/sh
exec tail -n +3 $0
set superusers=putyourusernamehere
password_pbkdf2 putyourusernamehere grub.pbkdf2.sha512.10000.3450C89...
You may want to add "--unrestricted" to the menu entries you want to boot without a password. For example within the file 10_linux :
10_linux:CLASS="--class gnu-linux --class gnu --class os --unrestricted"
Finally launch update-grub2 to generate the final configuration file /boot/grub/grub.cfg .
The Transmission daemon runs as the debian-transmission user. This user is (probably) not allowed to write to /home/pi/Desktop. You can verify this with ls -ld /home/pi/Desktop and interpreting the output.
Change the permissions/ownership on /home/pi/Desktop or let Transmission download to a file where it is allowed to store data.
You can give debian-transmission access to the folder with chown or setfacl. In case you're not inclined to do any research on that, the following will probably work:
$ setfacl -m u:debian-transmission:rwX /home/pi/Desktop
Best Answer
In case someone is suddenly having a similar issue:
In my case I've discovered that I had at least one of the trackers associated to a torrent whose domain was redirecting to 127.0.0.1. And the port where the tracker was running matched the port where my Transmission web interface is running. That is, every time that Transmission was requesting new peers, it tried to connect to..... Itself! And so triggering the brute force protection.
The solution in my case was to disallow local connections using iptables, because I always connect remotely: