WordPress „Das Verzeichnis uploads kann nicht angelegt werden. Ist das übergeordnete Verzeichnis durch den Server beschreibbar?“ trotz korrekter Rechte

Veröffentlicht am von — 1 Kommentar ↓

Nach diesem Effekt habe im im Auftrag der Admins hier soeben viel zu lange gesucht.

Screenshot: Das Verzeichnis uploads kann nicht angelegt werden. Ist das übergeordnete Verzeichnis durch den Server beschreibbar?

Wenn WordPress beim Upload von Daten in die Mediathek die Fehlermeldung anzeigt

Das Verzeichnis uploads kann nicht angelegt werden. Ist das übergeordnete Verzeichnis durch den Server beschreibbar?

liegt es oft an den Berechtigungen des Ordners /wp-content/uploads (Soll: 0755). Aber das ist es nicht immer.

Lösung

Nach dem Umzug eines WordPress Setups auf einen anderen Server war es vielmehr der upload_path aus der Datenbank, der noch auf ein altes Verzeichnis zeigte, das es so nicht mehr gibt. In der Tabelle wp_options gibt es dieses entscheidende Feld. Also ich kannte es bisher nicht 🙂

Also schnell am mysql cli gefixt:

UPDATE `wp_options` SET `option_value` = '/var/www/<PATH>' WHERE `wp_options`.`option_id` = 58 AND `wp_options`.`option_name` = 'upload_path';

und schon geht es wieder. Schade das WordPress die Fehlermeldung nicht etwas aussagekräftiger macht, zum Beispiel wohin es denn schreiben möchte.

Ich hätte viel eher diesen Beitrag von Lothar lesen sollen …

Outlook „Offline Adressbuch kann nicht heruntergeladen werden“ Fehler 0x8004010F

Veröffentlicht am von — Keine Kommentare ↓

Outlook versucht im Cache Modus immer das Offline Adressbuch (OAB) zu synchronisieren. Der Prozess bricht aber gerne mal mit dem wenig hilfreichen Fehler 0x8004010F ab.

Das Problem tritt gerne nach Migrationen auf, wenn ein Exchange Server auf ein anderes System (oder neue VErsion) migriert wurde. Dabei wird nämlich ein neues OfflineAddressBook (OAB) generiert, welches auch die Verteilung der Adresslisten übernimmt.

Die Adressliste auf den Clients ist dann meist auch nicht mehr richtig (veraltete Inhalte), allerdigns ist im OWA alles korrekt und aktuell.

Lösung

Zuerst: An der EMS prüfen ob das Adressbuch als „Default“ markiert ist:

Get-OfflineAddressBook | select Name, IsDefault

Hier sollte ein IsDefault: True zurückkommen.

Dann kann man mit prüfen, ob das OAB auch korrekt via Autodiscover verbreitet wird:

Get-OfflineAddressBook | select Name, VirtualDirectories, *web*

Und hier passiert gerne der Fehler. Exchange kennt zwei verschiedene Varianten, um dem Client den Zugriff auf das OAB zu wemöglichen:

  1. Man gibt an welche (IIS-) Virtual Directories vom Client abgefragt werden können um das OAB herunterzuladen
  2. Man erlaubt allen Virtual Directories den Download anzubieten

Microsoft (und wir) raten natürlich zur Variante Nummer 2:

Set-OfflineAddressBook "Standard-Offlineadressbuch" -GlobalWebDistributionEnabled $true

Der Name „Standart-Offlineadressbuch“ ist hier exemplarisch, alle existierenden Offline-Adressbücher listet man mit Get-OfflineAddressBook auf.

Windows 11 Taskleiste verkleinern („Kleine Symbole auf der Taskleiste verwenden“)

Veröffentlicht am von — 8 Kommentare ↓

Aus uns unerfindlichen Gründen hat Microsoft in Windows 11 (2022) die meisten praktischen und sinnvollen Funktionen der Taskleiste entfernt.

Nicht nur das man auf breiten Bildschirmen die Taskleiste nicht mehr an den Rand verschieben kann, sondern stattdessen nun noch mehr kostbaren (und knappen) vertikalen Platz verschenken muss, sondern die Taskliste ist nun auch erzwungenermaßen Rriesengroß.

Glücklicherweise lässt sich die unvernünftige Größe der Startleiste noch in der Registry schnell bändigen. Das geht sogar pro Benutzer.

Taskliste kleiner machen

Diese Registry-Einstellung skaliert die Taskbar:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced]

"TaskbarSi"=dword:00000000

Der DWORD 0 steht für „klein“, die 1 für Standard und 2 für groß.

REG-Downlaod für den schnellen Admin:

win11-taskleiste-kleinHerunterladen

Veeam Backup and Replication Logfile Pfade

Veröffentlicht am von — 4 Kommentare ↓

Veeam B&R schreibt äußerst großzügige Logfiles, die die Fehlersuche in den allermeisten Fällen wesentlich vereinfachen. Das ist großartige – bitte bitte Veeam, ändert das niemals 😉

Früher(TM) war nicht nur alles besser, sondern man konnte über das Hilfe-Menü den Logfile-Ort schnell und komfortabel aufrufen; doch das war eine sinnvolle und hilfreiche Funktion und musste daher selbstverständlich ersatzlos gestrichen werden.

Naja, nicht ganz ersatzlos, denn dafür gibt es jetzt den freundlichen „Support-Assistenten“, der erst (wortwörtlich) Gigabyteweise Diag-Files zusammenkopiert, diese über alle CPU-Kerne verteilt einpackt und dem Informationensuchenden Admin schon nach einigen Minuten (!) ein wieder neu zu entpackendes .zip mit ALLEN logs darin präsentiert. In vielen Fällen eher sinnfrei, wenn Ihr mich fragt.

Lösung: Für das schnelle debuggen sind die Logfiles hier versteckt:

  • Windows Server XP/2003: 
    %allusersprofile%\Application Data\VeeamBackup
  • Windows Server 2008/2008R2/7: 
    %allusersprofile%\VeeamBackup
  • Windows Server 2026/2019/2022 und Windows 10: (thx Dezibel)
    %allusersprofile%\Veeam
  • Linux: 
    /var/log/VeeamBackup/

vSphere vCLS VMs löschen, verschieben oder loswerden

Veröffentlicht am von — 3 Kommentare ↓

Die neuen „vSphere Cluster Services (vCLS)“ sind standardmäßig aktiviert und die zugehörigen VMs werden per Default in allen vSphere-Clustern ab 7.0U3 ausgeführt.

Diese vCLS-Gäste stellen eine „Teilautarkie“ sicher, so dass beispielweise bei einem Crash des vCenter Servers die Clusterdienste weiterhin ihre Arbeit tun. Achtung: der vCenter Server ist trotzdem erforderlich um DRS und HA zu konfigurieren (und Operationen ausführen) zu können.

vSphere Cluster Services (vCLS)

Ein lesenswerter Artikel zu dem Konzept findet sich in den vSphere Docs unter https://docs.vmware.com/de/VMware-vSphere/7.0/com.vmware.vsphere.resmgmt.doc/GUID-96BD6016-4BE7-4B1C-8269-568D1555B08C.html

vCLS ist immer aktiviert, wenn man ein Upgrade oder Setup mit vSphere 7.0U3 macht. Technisch wird vCLS auch schon beim vCenter Server-Upgrades aktiviert. Spannend: vCLS-VMs unterstützen keine eigenen Netzwerkkarten.

Sollen die vCLS-<ID> VMs bleiben?

Manchmal muss man die klebrigen vCLS VMs „eine Weile“ loswerden. Zum Beisipel wenn man ein Storage tauschen möchte oder sich der Cluster AUSGERECHNET ein Veeam_NFS Volume für das Deployment ausgesucht hat (ohne Storage Motion natürlich).

Unnötig sind Sie zudem auch, wenn man kleine Cluster ohne DRS oder andere Cluster-Features betriebt.

Prinzipiell sind die Dinger sehr robust: Man kann Sie jederzeit abschalten und sie gehen sofort von selber wieder an. Leider verhindert das auch das Verschieben auf andere Speicher (ohne Storage Motion).

Lösung: vCLS VMs abschalten

Man kann den Cluster aber zum Glück relativ einfach dazu bewegen, die vCLS-VMs selbstständig zu entfernen.

  • Cluster-ID kopieren: Links in der Bestandsliste den Cluster auswählen und die ID aus der Adresszeile kopieren. Zum Beispiel „domain-c37“
  • vCenter Konfigurieren: Links ganz oben das vCenter auswählen, dann rechts Konfigurieren > Erweitert > Einstellungen bearbeiten > neuen Wert hinzufügen
  • Der Wert lautet config.vcls.clusters.<CLUSTER-DOMAIN>.enabled und muss auf „False“ gesetzt werden

Sobald das gespeichert ist, verschwinden die vCLS-Maschinen innerhalb weniger Sekunden. Löscht man den Eintrag wieder (oder stellt ihn auf „True“) kommen die Maschinen zuverlässig und schnell wieder.