The problem may be (it was in my case) that there are firewall rules preventing NAT firewall rules for the virbr0 network device created by Vagrant via libvirt, which may look like the following (excerpt of iptables -L -n):
Accomplishing the simple often takes a day or two.
According to countless tutorials on the internet, in order for a working WoL, you need to fulfill the following preconditions (where point 4 below is rarely mentioned [that’s why this article exists]):
An ethernet hardware/card supporting WoL
Enabling WoL in the BIOS
Enabling the WoL feature on the ethernet card (usually using the user space tool ethtool)
Enabling the WoL feature in the Linux kernel (and this was the major pitfall for me)
Support of WoL can be checked for a given ethernet card in the following way:
ethtool | grep Wake-on
According to my own experiments on my local hardware, WoL seems to always be enabled by default:
Supports Wake-on: pumbg
Because it already prints Wake-on: g, signalling that WoL is enabled (for Magic Packets), one is tempted to not run ethtool -s <card_label> wol g to achieve the same.
However, this ethtool command does at least one other thing, being equivalent to the following:
And the main pitfall is: After a reboot, cat /sys/class/net/<card_label>/device/power/wakeup will return disabled.
That is why attempts to make WoL work without ethtool may fail. The feature will stay disabled in the Linux kernel, which will completely shut off the ethernet card in most powersave and power-off states. (I verified this observing the LEDs of a connected ethernet switch).
On modern Linux systems, given supporting hardware, it seems to be enough to write the string enabled to /sys/class/net/<card_label>/device/power/wakeup to make WoL work. ethtool doesn’t seem to be required any more for that, since Ethernet cards seem to already be configured properly by default. The Ethernet card will stay powered in most power-save and power-off states, so that it can receive Wake-on-LAN packets.
Note: This tutorial is based on Debian 10 and 11. It may or may not work in other environments.
Update 2021-04-11: Debian 11 (contains KDE Plasma 5.20.5) is already out. I just confirmed that the method presented here still works. The dialogs just look slightly different than in Debian 10. This does not warrant a new blog post, so I will simply update the current one.
While not a filesystem mount via the Linux kernel (such as I just described in a previous blog post), KIO GDrive (part of KDE) still enables KIO-aware applications (such as the Dolphin file manager, Kate editor, or Gwenview image viewer, etc.) to access, navigate, and edit Google Drive files.
kio-gdrive is available as a package in several Linux distributions. If installed, the Dolphin file manager will get an entry “Google Drive” under “Network”. There, an unprivileged desktop user can ‘mount’ a Google Drive account via a guided graphical configuration (during which the default browser will be opened where one needs to give KDE KAccounts permission to access the GoogleDrive account).
This method doesn’t provide access to Google Drive via a terminal; it integrates it nicely with a graphical desktop. The best part is that you don’t have to be root/superuser in order to do this, nor do you have to use the command line or write configuration files!
The following steps will walk you through the entire process.
Install the kio-gdrive Debian package. After installation, the Dolphin file manager immediately gets an entry called “Google Drive” under “Network”.
On Debian 11, click on “Google Drive”. On Debian 10, additionally click on “New account” under “Google Drive”:
A dialog window opens. It looks a bit differently in Debian 10 and 11. Click on the “+” button, and then on “Google”.
In a small web-frame dialog, Google will now ask you to give access to the KDE application. It again looks a bit differently in Debian 10 and 11.
Once you give permission, you will see a confirmation dialog:
Exit this dialog and you will be able to browse your files!