Wenn die Festplatte einer virtuellen Maschine volläuft, so kann im Gegensatz zu physikalischen Rechnern das Problem meist recht einfach behoben werden. Etwas spannender wird es, wenn die virtuelle Festplatte partitioniert ist und bei der Erweiterung eine andere Partition im Weg ist:

$ sudo fdisk -l /dev/sda
Disk /dev/sda: 30,18 GiB, 32408698880 bytes, 63298240 sectors
Disk model: VBOX HARDDISK   
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xf3f6188b

Device     Boot    Start      End  Sectors  Size Id Type
/dev/sda1  *        2048 61296639 61294592 29,2G 83 Linux
/dev/sda2       61298686 63297535  1998850  976M  5 Extended
/dev/sda5       61298688 63297535  1998848  976M 82 Linux swap / Solaris

Das oben stehende Beispiel zeigt eine solche Situation: die eigentliche Daten- bzw. Betriebssystempartition "/dev/sda1" kann nicht einfach vergrößert werden, da die erweiterte Partition "/dev/sda2" mit der darin enthaltenen Swap-Partition "/dev/sda5" direkt anschließend auf dem Datenträger liegt.

Sofern man nicht gerade mit einer virtuellen Maschine arbeitet, deren Verlust man verschmerzen kann, sollten die folgenden Schritte nicht ohne vorherige Komplettsicherung durchgeführt werden.
Es kann immer etwas schiefgehen und schlimmstenfalls steht man am Ende des Prozesses mit einer Maschine da, deren Partitionen beschädigt sind und die ggf. nicht mehr in der Lage ist, zu starten.

Weiterlesen

Während eine RDP-Verbindung zum GNOME-Desktop mit Debian 10 problemlos funktionierte, wurde nach einem Upgrade auf Debian 11 jeder Verbindungsversuch mit "Leider ist ein Problem aufgetreten." beendet:

Die Problematik ist sowohl auf Github unter "On Debian 11 upgraded install I get "Oh no! Something has gone wrong." when connecting." als auch in dem Debian Bug Report "xRDP connection results in Oh No ! something has gone wrong..Logout when Gnome Desktop used" dokumentiert, die Ursache liegt wohl in einem Fehler in der von Debian 11 ausgelieferten "xorgxrdp-0.2.12"-Version.

Da es aktuell kein fehlerbereinigtes Paket in den Standard-Paketquellen gibt, kann behelfsweise ein Paket von https://snapshot.debian.org/ verwendet werden. Die im oben genannten Github-Thread vorgeschlagenen Paketversionen "xorgxrdp_0.2.15-1_amd64.deb" sowie "xrdp_0.9.15-1_amd64.deb" laufen nach manueller Installation ohne weitere Abhängigkeiten in der Debian 11-Umgebung und ermöglichen wieder einen Zugriff auf den GNOME-Desktop mit RDP:

$ wget https://snapshot.debian.org/archive/debian/20210302T032219Z/pool/main/x/xorgxrdp/xorgxrdp_0.2.15-1_amd64.deb
...

$ wget https://snapshot.debian.org/archive/debian/20210302T032219Z/pool/main/x/xrdp/xrdp_0.9.15-1_amd64.deb
...

$ sudo apt install ./xorgxrdp_0.2.15-1_amd64.deb 
...
Die folgenden Pakete werden aktualisiert (Upgrade):
  xorgxrdp
1 aktualisiert, 0 neu installiert, 0 zu entfernen und 5 nicht aktualisiert.
...

$ sudo apt install ./xrdp_0.9.15-1_amd64.deb 
...
Die folgenden Pakete werden aktualisiert (Upgrade):
  xrdp
1 aktualisiert, 0 neu installiert, 0 zu entfernen und 5 nicht aktualisiert.
...

Während bei Debian cron-apt für die automatische Aktualisierung der Systeme sorgt, ist unter Oracle Linux yum-cron das passende Gegenstück.

Um (unabhängig von automatischen oder manuellen Aktualisierungen) die Menge der zu übertragenden Daten zu reduzieren, kann optional das Paket "deltarpm"

# yum install deltarpm

installiert werden.

Delta RPM packages contain the difference between an old and a new version of an RPM package. ... The delta RPM packages are even smaller in size than patch RPMs, which is an advantage when transferring update packages over the Internet. The drawback is that update operations with delta RPMs involved consume considerably more CPU cycles than plain or patch RPMs. [Quelle]

Anschließend wird das Paket "yum-cron" installiert:

# yum install yum-cron

Nach Installation liegt die zugehörige Konfigurationsdatei "yum-cron.conf" im Verzeichnis "/etc/yum" und kann dort bearbeitet werden.

Hier kann z.B. über den Parameter

update_cmd = security

die Art der abzuhandelnden Aktualisierungen oder über den Parameter

apply_updates = yes

nicht nur das Herunterladen, sondern auch das automatische Einspielen aktiviert sowie verschiedene Benachrichtigungsoptionen konfiguriert werden.

Als letzter Schritt muß noch noch der Dienst aktiviert und gestartet werden:

# systemctl start yum-cron
# systemctl enable yum-cron

Beim Klick auf eine lokal abgelegte Datei zeigte Windows nicht wie erwartet die Vorschau der Schriftart an, sondern lediglich eine Fehlermeldung.

Der Text der Fehlermeldung "Die angeforderte Datei ... ist keine gültige Schriftartendatei." ist zwar nicht grundlegend falsch, impliziert aber, daß die Datei selbst fehlerhaft wäre. Eine Überprüfung der Datei ergab, daß diese offensichtlich in Ordnung ist und z.B. auf einem Linux-System problemlos verwendet werden kann.

Der Grund für das Nicht-Anzeigen und die damit verbundene Fehlermeldung ist letztendlich kein Bug, sondern ein Feature, das im Beitrag "Blockieren von nicht vertrauenswürdigen Schriftarten in einem Unternehmen" von Microsoft dokumentiert ist:

Um Ihr Unternehmen vor Angriffen zu schützen ... haben wir das Feature zum Blockieren nicht vertrauenswürdiger Schriftarten erstellt. ... Nicht vertrauenswürdige Schriftarten sind alle Schriftarten, die außerhalb des Verzeichnisses %windir%/Fonts installiert sind.

In dem Beitrag wird auch erklärt, wie - sofern gewünscht - entweder über Gruppenrichtlinien oder die Registry das Verhalten von Windows angepasst werden kann. Sofern das Feature deaktiviert wird, können nach einem Neustart auch wieder Schriftarten, welche außerhalb von "%windir%/Fonts" liegen, per Doppelklick angezeigt und über die Vorschau installiert werden.

Eine Meldung in der Art von "Zugriff auf ... blockiert." oder im Idealfall sogar "Kein Zugriff auf Schriftartendateien außerhalb von %windir%/Fonts möglich." wäre sicherlich zielführender und würde einigen Admins jede Menge Zeit und unnötige Sucherei ersparen.

Bei Problemen beim Zugriff auf Netzwerkfreigaben ist Windows leider wenig auskunftsfreudig und der Text im "Netzwerkfehler"-Dialog nicht unbedingt hilfreich:

Im konkreten Fall ging es um das Scheitern des Zugriffs auf eine Netzwerkfreigabe ohne Authentifizierung, welche über Samba realisiert wurde.

Bei der Ursachenforschung half der Versuch, die Verbindung über die Kommandozeile herzustellen:

C:\>net use \\192.168.180.221\htdocs
Systemfehler 1272 aufgetreten.

Sie können nicht auf diesen freigegebenen Ordner zugreifen, weil der Zugriff nicht 
authentifizierter Gäste durch die Sicherheitsrichtlinien Ihrer Organisation blockiert werden. Diese
Richtlinien helfen, Ihren PC vor unsicheren oder bösartigen Geräten im Netzwerk zu schützen.

Die Suche nach Teilen der von "net" ausgegebenen Fehlermeldung führt zum Beitrag "Gastzugriff in SMB2 und SMB3 in Windows standardmäßig deaktiviert", aus dem hervorgeht, daß es sich um ein Feature und keinen Bug handelt.

Dort ist auch erklärt, wie sich der Zugriff trotzdem realisieren lässt - entweder über die Gruppenrichtlinienverwaltung oder über das Setzen eines Registrierungsschlüssels:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters] "AllowInsecureGuestAuth"=dword:1

Das Setzen des Schlüssels wird direkt berücksichtigt, der Neustart eines Dienstes oder des Systems ist nicht notwendig.