If using Microsoft Authenticator, you may receive the following error message when trying to remove an account:

You need to disable backup to delete <account>.

This can happen if you are trying to delete the account that is also acting as the Recovery Account for authenticator backups.  To resolve, go into the Microsoft Authenticator settings.  Find the section titled Backup, then disable backup.  For example, on iOS this will be via iCloud Backup.

It will then ask whether you want to delete your backup:  You will no longer be able to recover your accounts.

Click OK. You will receive confirmation that Backup successfully deleted with a Cancel button.

Go back to the main Authenticator screen. You will now be able to delete the account from Microsoft Authenticator.

One case study involved an Ubuntu 20.04 (Focal Fossa) system that was protected with Fail2fan.  However the server was also protected with Cloudflare, so there was some work needed to get the remote IP of the attacker (this topic was covered in another post). If you try to ban the offender’s real IP (not the Cloudflare IP) with that configuration, you may receive messages in the fail2ban.log that look similar to the below:

fail2ban.observer INFO [jail] Found x.x.x.x, bad
fail2ban.actions NOTICE [jail] x.x.x.x already banned

You should also see the ban in iptables:

sudo iptables -L

However with the bans in place, the offending IP can still access the resource. The root cause is because the attack is originating from Cloudflare.

The solution is to ban and unban attacker’s remote IPs using Cloudflare’s API for their firewall.  Fail2ban has a built in actions.d/cloudflare.conf to help with that.   However with the Fail2ban version (0.11.1) available in Ubuntu 20.04 , the action file included was not completely functional, especially on the unban side.  The trick is  replace it (or use an action local file) using the latest action file on GitHub:

https://github.com/fail2ban/fail2ban/blob/master/config/action.d/cloudflare.conf

Duplicate the latest action file, then:

1. Populate cftoken with your Global API key from Cloudflare
2. Populate cfuser with the email address of your Cloudflare account.

Save the new action file (e.g., cloudflare.conf or cloudflare.local).  Before proceeding further, flush out any old bans that may be present in Fail2ban from previous attempts at banning, doing one or more of the following:

sudo fail2ban-client set JAILNAME unbanip x.x.x.x

Once complete, the next step is to update your jail to have the following line (NOTE – if your action file is not called cloudflare.conf or cloudflare.local, change it below accordingly):
action = cloudflare

Save the jail and then reload Fail2ban:

sudo service fail2ban reload

Test to see if the banning works. You can monitor fail2ban in real time using the command:

sudo tail -f /var/log/fail2ban.log

As of today, you can view and manage bans in your Cloudflare account at Websites -> “Your-Site” -> Security -> WAF -> Tools.  Any bans that come in through the API will have a note “Fail2Ban JAILNAME”  under the IP address.

On Ubuntu 20.04 (Focal Fossa) running PHP 8.2, you may run into an issue after installing the latest phpMyAdmin (5.2.1) using the PPA (ppa:phpmyadmin/ppa).

When you try to log in to phpMyAdmin, you will get the following message:

 Error: Unknown named parameter $$dbi

I first found discussion about the issue on Stack Overflow, but neither solutions would result in staying on the PPA:
https://stackoverflow.com/questions/76213404/error-unknown-named-parameter-dbi-in-phpmyadmin-5-2-1

However the issue has been identified by the development team:
https://github.com/phpmyadmin/phpmyadmin/issues/16968
https://github.com/phpmyadmin/phpmyadmin/wiki/DebianUbuntu#known-issues
https://github.com/phpmyadmin/phpmyadmin/issues/18498
https://github.com/symfony/symfony/commit/8e34978e4e2c4bf7dac97e44e904368c4cfb54f8

The quick steps to fix the problem:

1. Edit the file (nano, vi, etc.)

   /usr/share/php/Symfony/Component/DependencyInjection/ContainerBuilder.php

2. Change this line

   $service = null === $r->getConstructor() ? $r->newInstance() : $r->newInstanceArgs($arguments);

   to look as follows:

   $service = null === $r->getConstructor() ? $r->newInstance() : $r->newInstanceArgs(array_values($arguments));

3. Save and close the file.  Refresh the browser (or try to log in again) and you should now have a working phpMyAdmin instance.

If you have a Sprint branded Blackberry phone (in this case a Bold 9930 running OS 7.1) that has an old phone number (MDN) on it, you may find that the number remains even after performing a Security Wipe of the data from the device. However, you can remove easily remove it with a device reset using these steps:

1. From the home screen, press the Send key.
2. Dial ##72786.
3. Tap Continue (Call ##72786)
4. You will receive a prompt: SCRTN will change to factory default value for DSS
5. Choose Continue
6. You will receive another prompt: SCRTN Successful. The device will now reset to apply the necessary changes
7. Click OK
8. The device will restart and the old phone number will have been removed.

On a Blackberry (in this case a Bold 9930 running Blackberry OS 7.1), you can check for forced encryption on the device by going to: Options -> Security -> Encryption.

There you will see a lock symbol illuminated for Device Memory and possibly Media Card as well.

Under Options -> Security -> Password, you may also have some options forced.

You can view all of the policies that are being forced on the device (typically on a company phone) by going to Options -> Security -> Security Status Information -> View IT Policy button.

You may have already tried to remove encryption by wiping the phone via Options -> Security -> Security Wipe. While this may remove data on the device and memory card, it doesn’t remove the IT policies (such as password, encryption, etc.).

To fully reset the phone, you will need to use the Blackberry Desktop Software.  As of 2023 the software carries the same name as the original, but has been repurposed for Blackberry VPN service (https://www.blackberry.com/content/dam/blackberry-com/Documents/pdf/desktop/br-desktop.pdf).   Blackberry phones are no longer supported by the version of the software that is available for download. (https://www.blackberry.com/us/en/support/downloads/notice).

Fortunately, you can still acquire the software that works on either Windows or Mac using the Internet Archive project.  A version of Blackberry Desktop that supports Blackberry OS 7.1 and earlier is available. Software is also available for Blackberry 10 OS (Blackberry Link and Blackberry Blend).

https://archive.org/details/blackberry-desktop-software_202112

You can check the model of phone and also the version of Blackberry OS running on the device by going to Options -> Device -> About Device Versions.   Download the appropriate software from the link above.

For a Bold 9930 you’ll need BlackBerry Desktop software for BlackBerry 7.1 OS and earlier.  

If running Windows 10, use the link above to download:
Desktop Software v7.1.0 B42 (Multilanguage)
710_b042_multilanguage.exe

If on Mac OS, download:
BlackBerry Mac Desktop Software v2.4.0.18 (Mac OS)
BlackBerry Desktop Software.dmg

Once installed, connect the device to the computer (in this case using a micro USB cable) and launch the software.  Verify the phone is detected.   In the top right of the software there is a box with a question mark inside of it.  Click it, then choose -> Support resources -> Support tools.  There you will have the option to Reset to Factory Settings.  Click the Reset button.

If it gets interrupted or you receive an error related to the Application Loader, simply repeat the steps.

Once complete, the device should be free of any forced policies.

If you are having trouble getting Q-Flash Plus to work, below are some tips:

1. Use a dedicated USB disk, freshly formatted using FAT32 with Windows explorer.  I’ve read some tutorials that said smaller size thumb drives are better but I had no issues with a Microcenter 32GB flash drive.
2. Copy the latest BIOS file to the root of a flash drive. Make sure you can view file extensions in Windows explorer.   The original BIOS filename should end in a period and 3 digits, (e.g., A520MS2H.15e).    Rename it to GIGABYTE.BIN
3. Connect the flash drive to the correct USB port on the Gigabyte motherboard. The port should be uniquely labeled on the rear I/O shield, such as “BIOS” or “Q-FLASH PLUS”.
4. Attach the 24 pin ATX and 8 Pin CPU cables from the power supply. An installed CPU, GPU and/or memory are optional.
5. Press and release (not hold down) the QFLASH_PLUS button on the motherboard (do not use the regular power button).
6. You should see activity on your flash drive.  If activity stops and the Q-Flash LED does not illuminate, then try steps 2 and 3 again using a different flash drive.
7. When the LED stops, the flash is complete. Remove the flash drive and power cycle the system.

At the very end of an upgrade from version 5 to version 6 of OMV, I received the error

Updating workbench configuration files ...
Restarting engine daemon ...
Errors were encountered while processing:
grub-pc
W: --force-yes is deprecated, use one of the options starting with --allow instead.
E: Sub-process /usr/bin/dpkg returned an error code (1)

To finish the install, the solution is to simply run this command:

sudo dpkg --configure -a

I had an unclean shutdown of OMV and when it restarted, all of the shares were no longer accessible.

Also when rebooting OMV, you may see a console message related to “a start job is running for /dev/disk/by-label/your-volume-name” that takes many seconds before it will proceed.

Logging into the OMV GUI, the array was completely gone (under RAID Management).  The file system also had a status of “Missing” (under File Systems).

Here are the steps used to restore the array

1. Log in to the OMV console and run the command below to get the name of the array (e.g., md0) and a list of drives contained within it (e.g., sda, sdb, etc.).

   cat /proc/mdstat

2. Using the name of the array from above (e.g., md0), run this command to get the list of drives that are contained within the array (e.g., /dev/sda, /dev/sdb, etc.)

   mdadm --detail /dev/md0

3. Stop the array

   mdadm --stop /dev/md0

4. Try to manually assemble the array, replacing the letters in the brackets with a list of the last letter of each device (e.g., a, b, etc.)

   mdadm /dev/md0 --assemble /dev/sd[ab]

5. If everything is fine, you should see only a message from mdadm that the array has been started with the specified number of drives.
6. If you receive a message that a device is busy – skipping, then power off the machine completely. Power on and repeat steps 2-4 (be sure to confirm whether any drive letters changed).
7. In the GUI, confirm the array is appearing under RAID Management. It should have a State of clean, resyncing (pending)
   
8. Go to File Systems, select the device that represents the array. Click the Mount button.
9. If everything is fine, then after a short time the file system should change status to “Online” and the shares will become accessible again.
10. Go back to RAID Management and confirm the State of the array is now clean, resyncing.

When rebooting a Windows 10 system that had ICS enabled, the settings would be lost. Clients that were using the shared connection could no longer access it even though it still showed enabled. The workaround was to disable and re-enable the checkbox button for: Allow other network users to connect through this computer’s Internet connection.

The long term solution involves 2 changes, taken from the below article:
https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/ics-not-work-after-computer-or-service-restart

1. Modify the service titled Internet Connection Sharing (ICS) using the Control Panel -> Services.  Change Startup Type to Automatic.
2. In the following registry location, create a DWORD titled EnableRebootPersistConnection and set a value of 1:
   HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\SharedAccess

After the above changes, configure ICS into a working condition (if necessary toggle the checkbox) and then reboot the system.

When an X58 + ICH10 based machine (Dell Precision T3500) was upgraded to ESXi 7, the storage adapter and associated datastore was lost.  The ICH10 in this case was not playing well with the native vmw_ahci driver.  In AHCI mode, the adapter shows up as a 6 port controller in vSphere (Host -> Manage ->  Hardware of PCI devices. However none of the attached drives appear under Storage.  Also attempting to toggle PCI passthrough for the device results in an error:

An error occurred during host configuration.  Operation failed, diagnostics report: GetDeviceID failed.

Refreshing vSphere would then show as the host needing a reboot for it to take effect. However upon rebooting passthrough is still  disabled / not active.

To resolve, the SATA adapter was switched from AHCI to IDE / ATA mode in the BIOS.  This allowed the controller and all attached drives to appear in vSphere by using the native vmkata driver.  This change will also passthrough to be enabled, but it requires a reboot.

However another issue was that a VMFS datastore on the drive attached to this controller was no longer accessible.  To resolve, the datastore had to be force mounted. These steps were used to manually mount the datastore:

1. In the console / shell:

   esxcli storage vmfs snapshot list

2. Check fore an output similar to this:Volume Name: datastore1
   VMFS UUID: <snip>
   Can mount: true
   Reason for un-mountability:
   Can resignature: true
   Reason for non-resignaturability:
   Unresolved Extent Count: 1
3. Determine the Volume Name, e.g., (datastore1), this acts as the label
4. Mount it using the label. In this example, datastore1:

   esxcli storage vmfs snapshot mount -l datastore1

5. Refresh the Storage section of vSphere

Note: performance in ATA / IDE mode may be reduced compared to AHCI