Monthly Archives: August 2022

Bind for 0.0.0.0:443 failed: port is already allocated

 in Docker  tagged bind / docker / docker-compose / images / pull / restart / service / timeout / update by

On a Docker installation that we have, we updated the image files for our containers using the following command:

docker images --format "{{.Repository}}:{{.Tag}}" | grep ':latest' | xargs -L1 docker pull;

Then we tried to update our container, as usual, using the docker-compose command.

export COMPOSE_HTTP_TIMEOUT=180; # We extend the timeout to ensure there is enough time for all containers to start
docker-compose up -d --remove-orphans;

Unfortunately, we got the following error:

export COMPOSE_HTTP_TIMEOUT=180;
docker-compose up -d --remove-orphans;

Starting entry ... 
Starting entry ... error

ERROR: for entry  Cannot start service entry: driver failed programming external connectivity on endpoint entry (d3a5d95f55c4e872801e92b1f32d9693553bd553c414a371b8ba903cb48c2bd5): Bind for 0.0.0.0:443 failed: port is already allocated

ERROR: for entry  Cannot start service entry: driver failed programming external connectivity on endpoint entry (d3a5d95f55c4e872801e92b1f32d9693553bd553c414a371b8ba903cb48c2bd5): Bind for 0.0.0.0:443 failed: port is already allocated
ERROR: Encountered errors while bringing up the project.

We used the docker container ls command to check which container was hoarding port 443, but none was doing so. Because of this, we assumed that docker ran into a bug. The first step we took (and the last) which solved the problem was to restart the docker service as follows:

sudo service docker restart;

This command was enough to fix our problem without messing with docker further.

BitLocker needs your recovery key to unlock your drive because Secure Boot policy has unexpectedly changed

 in Windows  tagged BitLocker / windows / Windows 10 / Windows 11 by

Oh, the joy of wrong configurations!

Recently, a person brought us this laptop to “fix.”
The previous day, the owner performed some Windows updates, and after restarting, the machine got this error.
After inquiring with him, we got the following information:

  • He did not possess a BitLocker recovery key with a length of 48 digits.
  • He had never even attempted to put one up, save it anywhere, or copy it to a USB drive, nor had he ever printed it off.
  • He logged into his Microsoft and Azure account, receiving the message “You don’t have any BitLocker recovery keys uploaded to your Microsoft account.” even though his device was listed there.
  • He could not locate the recovery key after attempting to follow the published instructions published by Microsoft.

If the information we got from that person is correct, then it means that the last Windows update cost that person inadvertently to lose all data that he did not back up in an external media or service. (Cracking the recovery key for BitLocker is, of course, out of the question for non-magical or extremely rich people with unlimited resources.)

Our only pieces of advice are the following:

  • Wait a few days before updating your PCs. Although this is not a safe practice, it might give the people responsible for this issue some time to fix it with a hotfix patch or similar.
  • In the meantime, perform timely backups of your data to external media or services.
  • If you are familiar with the Windows OS ecosystem, check your BitDefender settings. If that service is active and you do not have the recovery key, disable it and then reactivate it. It will produce a new pair of passwords and recovery keys that you can save for future use.

Error mounting filesystem

 in GNU/Linux  tagged bash / Disk Image Mounter / e01 / ewf / ewf-tools / ewfmount / gnome / GNU/Linux / mount / ubuntu / udisks-error-quark by

After installing the ewf-tools the right way on a GNU/Linux Ubuntu machine, we executed the following command to create the ewf1 mounting point for our .E01 image:

mkdir /mnt/ewf;
ewfmount ./DISK.E01 /mnt/ewf/;

After the operating system created the mounting point, we opened the ewf1 file that appeared in /mnt/ewf/ using the Gnome Disk Image Mounter. This action made a new entry in the Gnome Disks Utility, showing our new disk.

After clicking on the play button (labeled Mount selected partition) we got the following error:

We then tried to use the terminal to gain more control over the mounting parameters. To proceed with the following commands, we copied the Device value, which was /dev/loop54p3 in this case.

$ mkdir /mnt/loc;
$ sudo mount /dev/loop54p3 /mnt/loc;
mount: /mnt/loc: cannot mount /dev/loop54p3 read-only.
$ sudo mount -o ro /dev/loop54p3 /mnt/loc;
mount: /mnt/loc: cannot mount /dev/loop54p3 read-only.
$ sudo mount -o ro,loop /dev/loop54p3 /mnt/loc;
mount: /mnt/loc: cannot mount /dev/loop58 read-only.
$ sudo mount -o ro,loop -t ext4 /dev/loop54p3 /mnt/loc;
mount: /mnt/loc: cannot mount /dev/loop58 read-only.
$ sudo mount -o ro,norecovery,loop -t ext4 /dev/loop54p3 /mnt/loc;

The command that worked for us was the following:

sudo mount -o ro,norecovery,loop -t ext4 /dev/loop54p3 /mnt/loc;

The parameter that did the trick was norecovery. norecovery/noload instructs the system not to load the journal on mounting. Note that if the filesystem was not unmounted cleanly, skipping the journal replay will lead to the filesystem containing inconsistencies that can lead to any number of problems. This problem occurred because the machine did not shut down properly before it had its image cloned, so after we mount, we might not get the latest state of the disk.

How to access VMFS Datastore from Ubuntu GNU/Linux

 in GNU/Linux  tagged bash / Datastore / disks / ESXi / fdisk / fdisk -l / gnome / gnome-disk-utility / gnome-disks / GNU/Linux / ubuntu / VMFS / VMFS Datastore / vmfs-fuse / vmfs-tools / vmfs6-fuse / vmfs6-tools by

Suppose the ESXi host fails, but the server’s local disk or disks are still operational. In that case, it is always possible to copy the virtual machine files (both data drives and configuration files) from the VMFS datastore and run the VM on a different server. This is true even if the ESXi host fails (even on VMware Workstation or Hyper-V). The most significant issue is that the widely used operating systems, such as Windows and Linux, do not have a VMFS driver, which causes them to be unable to recognize a partition that automatically has the VMFS file system.

To mount a VMFS file system on an Ubuntu, we will need to install the vmfs-tools package.

sudo apt-get install vmfs-tools;

Then, we need to create a folder where we will perform the mount later on:

# The folders does not have to be in the /mnt path, it can be anywhere on your file system where you have access.
sudo mkdir /mnt/vmfs;

Following that, we need to identify the disk we want to mount. There are two popular ways to do so, and the first is by executing the command fdisk -l on the terminal, which will show all physical disks attached to your system. You will get results that are similar to the ones below:

sudo fdisk -l;

...

Disk /dev/loop51: 884,85 GiB, 950075898880 bytes, 1855616990 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

From these results, the drive’s path is essential information for us. In this case, it was /dev/loop51.

The second method is to use the Gnome Disks Utility:

When you start the application, you will get an image similar to this:

If you have a physical VMFS datastore hard drive, it will appear on the list on the left. You will get more information on the right panel by clicking on it. The critical information is the value after the label Device. In this case, the vital value was /dev/loop51.

If you do not have a physical drive but an image of a drive, you can attach it by clicking on the menu button with the three lines on the top left and then selecting the Attach Disk Image... (.iso, .img) option. A new window will open, allowing you to navigate and find your image file.

After we acquire the path to the physical drive or the image file, we can mount it using the following command:

sudo vmfs-fuse /dev/loop51 /mnt/vmfs;

In case you get the following error:

VMFS: Unsupported version 6
Unable to open device/file "/dev/loop51".
Unable to open filesystem

Then, you need to install the package that can handle VMFS version 6. To install, use the following command:

sudo apt-get install vmfs6-tools;

Trying again to mount, this time with the tools that are appropriate for version 6, should do the trick:

sudo vmfs6-fuse /dev/loop51 /mnt/vmfs;

To unmount, we need to execute the following:

sudo umount /mnt/vmfs;