Docker not working

Bare Metal and VPS
1

Hello,

I can't run the docker command:

[RESCUE] root@vps-a71e1ee4:~ $ sudo docker --version
sudo: docker: command not found
[RESCUE] root@vps-a71e1ee4:~ $ docker --version
-bash: docker: command not found
[RESCUE] root@vps-a71e1ee4:~ $ df -h
Filesystem Size Used Avail Use% Mounted on
udev 1.9G 0 1.9G 0% /dev
tmpfs 382M 672K 382M 1% /run
/dev/sda1 2.9G 2.2G 540M 81% /
tmpfs 1.9G 0 1.9G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
[RESCUE] root@vps-a71e1ee4:~ $

I reinstalled it but it's the same....

Thank you for your help

2

Hi,

[RESCUE] root@vps-a71e1ee4:~ $ sudo docker --version

You are root on your VPS, so sudo is not needed.
You seem to be in RESCUE mode, so it's normal that it doesn't work :slight_smile:

I reinstalled it but it's the same....

How did you install it?

3

Indeed, I think that's what @TTY mentioned to you.

You need to change the boot mode from the client area. Look for the Boot option and make sure “Boot from hard drive” is selected.

Restart the VPS, connect via SSH and if you don’t see [RESCUE] in the prompt, then you’re already in your real system.

Let us know, cheers.
Sergio Turpín

4

Hello
Thanks already for your reply
So I start the VPS in normal mode,
and then connect via SSH with Windows' admin terminal
I need to log in as root but I don’t know the password.....
How can I find it?

5

Hi @DanielG34

You don’t need to do it with the root user; if you know the password of your primary account (the one that was sent to you by email when you reinstalled the VPS, for example debian), you can SSH in with that user and then set a password for root.

ssh debian@your-ip

Even if you can do it, it is not recommended to use root for regular SSH connections. It is safer to use a user with sudo and run the commands that require privileges with sudo.

Regards,
Sergio Turpín

7

Good morning @DanielG34

Take a look at this guide:

https://docs.ovhcloud.com/en/guides/bare-metal-cloud/virtual-private-servers/starting-with-a-vps

There is a specific guide for when you have lost the root or your user password. The procedure involves booting the VPS in rescue mode, mounting the system partition, and changing the password from there:

https://support.us.ovhcloud.com/hc/en-us/articles/4412634196115-How-to-Change-the-Root-Password-on-a-VPS

Let us know how it goes, cheers.
Sergio Turpín

8

hello,
I can't get it to work..
I followed the guide to the letter.
Not knowing what the system's partition was, I tried with sdb1 then another with sda1
I still get the following messages :

PS C:\Users\Proprietaire> ssh root@92.222.67.200
The authenticity of host '92.222.67.200 (92.222.67.200)' can't be established.
ED25519 key fingerprint is SHA256:YFTngis4tdegcBD3sPbmIFBpEbR5aN7uDaWlLfOHkdc.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '92.222.67.200' (ED25519) to the list of known hosts.
root@92.222.67.200's password:
Permission denied, please try again.
root@92.222.67.200's password:
Permission denied, please try again.
root@92.222.67.200's password:
root@92.222.67.200: Permission denied (publickey,password).
PS C:\Users\Proprietaire>
PS C:\Users\Proprietaire> ssh debian@92.222.67.200
debian@92.222.67.200's password:
Permission denied, please try again.
debian@92.222.67.200's password:
Permission denied, please try again.
debian@92.222.67.200's password:
debian@92.222.67.200: Permission denied (publickey,password).

best regards

Daniel GEORGES

9

Hi @DanielG34

The error "Permission denied" means you are trying to access with the wrong username and password.

You should do the following:

  1. Boot into rescue mode; as I mentioned before you can do it from the client area.
  2. OVHcloud will send you an automatic email with the root user and a temporary password to access rescue mode.
  3. Connect via SSH to the rescue mode
    ssh root@92.222.67.200
  4. Once inside, run lsblk to see your disks. The main disk of your VPS is the 40 GB one (sdb), and the partition that contains your system is sdb1. Do not use sda1; that belongs to the rescue system.
  5. Change the password of your user.
    passwd debian
    If you don’t know which it is, try debian, ubuntu or rocky, which are the most common.
  6. Reboot in normal mode. Exit the chroot with the exit command, unmount the disk with umount /mnt/root and reboot the VPS from the client area.
  7. Connect with your user and the new password, not with the root user.

Let me know how it goes, best regards.
Sergio Turpín

10

Hello,
I find the system partition (sdb1) quite full.
I have error messages.

Here is my log:

[RESCUE] root@vps-a71e1ee4:~ $
[RESCUE] root@vps-a71e1ee4:~ $ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 2.9G 0 disk
└─sda1 8:1 0 2.9G 0 part /
sdb 8:16 0 40G 0 disk
├─sdb1 8:17 0 38.9G 0 part
├─sdb13 8:29 0 1023M 0 part
├─sdb14 8:30 0 4M 0 part
└─sdb15 8:31 0 106M 0 part
[RESCUE] root@vps-a71e1ee4:~ $ df -h
Filesystem Size Used Avail Use% Mounted on
udev 1.9G 0 1.9G 0% /dev
tmpfs 382M 516K 382M 1% /run
/dev/sda1 2.9G 2.4G 308M 89% /
tmpfs 1.9G 0 1.9G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
[RESCUE] root@vps-a71e1ee4:~ $ fdisk -l
Disk /dev/sda: 2.93 GiB, 3145728000 bytes, 6144000 sectors
Disk model: QEMU 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: 0xd39b2f6a

Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 6141951 6139904 2.9G 83 Linux

Disk /dev/sdb: 40 GiB, 42949672960 bytes, 83886080 sectors
Disk model: QEMU 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: gpt
Disk identifier: 0EA9B1F3-399D-430C-B140-EA55EC6DB2F4

Device Start End Sectors Size Type
/dev/sdb1 2324480 83886046 81561567 38.9G Linux root (x86-64)
/dev/sdb13 2048 2097152 2095105 1023M Linux extended boot
/dev/sdb14 2099200 2107391 8192 4M BIOS boot
/dev/sdb15 2107392 2324479 217088 106M EFI System

Partition table entries are not in disk order.
[RESCUE] root@vps-a71e1ee4:~ $

[RESCUE] root@vps-a71e1ee4:~ $ mkdir -p /mnt/sdb1
[RESCUE] root@vps-a71e1ee4:~ $ mount /dev/sdb1 /mnt/sdb1
[RESCUE] root@vps-a71e1ee4:~ $ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 2.9G 0 disk
└─sda1 8:1 0 2.9G 0 part /
sdb 8:16 0 40G 0 disk
├─sdb1 8:17 0 38.9G 0 part /mnt/sdb1
├─sdb13 8:29 0 1023M 0 part
├─sdb14 8:30 0 4M 0 part
└─sdb15 8:31 0 106M 0 part

Filesystem Size Used Avail Use% Mounted on
udev 1.9G 0 1.9G 0% /dev
tmpfs 382M 564K 382M 1% /run
/dev/sda1 2.9G 2.2G 557M 80% /
tmpfs 1.9G 0 1.9G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
/dev/sdb1 38G 34G 4.2G 90% /mnt/sdb1

[RESCUE] root@vps-a71e1ee4:~ $
[RESCUE] root@vps-a71e1ee4:~ $ chroot /mnt/sdb1/

thread 'main' (1181) panicked at /build/rust-coreutils-u5JpDp/rust-coreutils-0.8.0/rust-vendor/rustix/src/backend/linux_raw/param/auxv.rs:269:22:
called Result::unwrap() on an Err value: ()
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
Aborted

thread 'main' (1183) panicked at /build/rust-coreutils-u5JpDp/rust-coreutils-0.8.0/rust-vendor/rustix/src/backend/linux_raw/param/auxv.rs:269:22:
called Result::unwrap() on an Err value: ()
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
Aborted
/usr/bin/lesspipe: 349: [: =: unexpected operator

thread 'main' (1184) panicked at /build/rust-coreutils-u5JpDp/rust-coreutils-0.8.0/rust-vendor/rustix/src/backend/linux_raw/param/auxv.rs:269:22:
called Result::unwrap() on an Err value: ()
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
root@vps-a71e1ee4:/#

11

Why is the message hidden

12

It's certainly because of the so-called artificial intelligence. :clown_face:

13

I am resubmitting the message

Hello,
I find the system partition (sdb1) quite full
I have error messages

Here is my log

[RESCUE] root@vps-a71e1ee4:~ $
[RESCUE] root@vps-a71e1ee4:~ $ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 2.9G 0 disk
└─sda1 8:1 0 2.9G 0 part /
sdb 8:16 0 40G 0 disk
├─sdb1 8:17 0 38.9G 0 part
├─sdb13 8:29 0 1023M 0 part
├─sdb14 8:30 0 4M 0 part
└─sdb15 8:31 0 106M 0 part
[RESCUE] root@vps-a71e1ee4:~ $ df -h
Filesystem Size Used Avail Use% Mounted on
udev 1.9G 0 1.9G 0% /dev
tmpfs 382M 516K 382M 1% /run
/dev/sda1 2.9G 2.4G 308M 89% /
tmpfs 1.9G 0 1.9G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
[RESCUE] root@vps-a71e1ee4:~ $ fdisk -l
Disk /dev/sda: 2.93 GiB, 3145728000 bytes, 6144000 sectors
Disk model: QEMU 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: 0xd39b2f6a

Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 6141951 6139904 2.9G 83 Linux

Disk /dev/sdb: 40 GiB, 42949672960 bytes, 83886080 sectors
Disk model: QEMU 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: gpt
Disk identifier: 0EA9B1F3-399D-430C-B140-EA55EC6DB2F4

Device Start End Sectors Size Type
/dev/sdb1 2324480 83886046 81561567 38.9G Linux root (x86-64)
/dev/sdb13 2048 2097152 2095105 1023M Linux extended boot
/dev/sdb14 2099200 2107391 8192 4M BIOS boot
/dev/sdb15 2107392 2324479 217088 106M EFI System

Partition table entries are not in disk order.
[RESCUE] root@vps-a71e1ee4:~ $

[RESCUE] root@vps-a71e1ee4:~ $ mkdir -p /mnt/sdb1
[RESCUE] root@vps-a71e1ee4:~ $ mount /dev/sdb1 /mnt/sdb1
[RESCUE] root@vps-a71e1ee4:~ $ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 2.9G 0 disk
└─sda1 8:1 0 2.9G 0 part /
sdb 8:16 0 40G 0 disk
├─sdb1 8:17 0 38.9G 0 part /mnt/sdb1
├─sdb13 8:29 0 1023M 0 part
├─sdb14 8:30 0 4M 0 part
└─sdb15 8:31 0 106M 0 part

Filesystem Size Used Avail Use% Mounted on
udev 1.9G 0 1.9G 0% /dev
tmpfs 382M 564K 382M 1% /run
/dev/sda1 2.9G 2.2G 557M 80% /
tmpfs 1.9G 0 1.9G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
/dev/sdb1 38G 34G 4.2G 90% /mnt/sdb1

[RESCUE] root@vps-a71e1ee4:~ $
[RESCUE] root@vps-a71e1ee4:~ $ chroot /mnt/sdb1/

thread 'main' (1181) panicked at /build/rust-coreutils-u5JpDp/rust-coreutils-0.8.0/rust-vendor/rustix/src/backend/linux_raw/param/auxv.rs:269:22:
called Result::unwrap() on an Err value: ()
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
Aborted

thread 'main' (1183) panicked at /build/rust-coreutils-u5JpDp/rust-coreutils-0.8.0/rust-vendor/rustix/src/backend/linux_raw/param/auxv.rs:269:22:
called Result::unwrap() on an Err value: ()
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
Aborted
/usr/bin/lesspipe: 349: [: =: unexpected operator

thread 'main' (1184) panicked at /build/rust-coreutils-u5JpDp/rust-coreutils-0.8.0/rust-vendor/rustix/src/backend/linux_raw/param/auxv.rs:269:22:
called Result::unwrap() on an Err value: ()
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
root@vps-a71e1ee4:/#

14

Hi @DanielG34

The error you see, that thread 'main' panicked... Aborted, is a failure of the chroot program that comes in the OVH rescue system. It’s not your configuration’s fault nor your partition’s.

Despite that error, the chroot has indeed worked. Notice the last line of your log: the prompt has changed to root@vps-a71e1ee4:/#. That means you are already inside your system.

Do the following:

Run cat /etc/passwd to see the list of users. It’s probably debian.

Run passwd username

Type exit to leave the chroot, unmount the disk with umount /mnt/sdb1 and reboot the VPS.

Let me know, cheers :waving_hand:
Sergio Turpín

15

I entered the following commands

root@vps-a71e1ee4:/# cat /etc/passwd

thread 'main' (902) panicked at /build/rust-coreutils-u5JpDp/rust-coreutils-0.8.0/rust-vendor/rustix/src/backend/linux_raw/param/auxv.rs:269:22:
called Result::unwrap() on an Err value: ()
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
Aborted cat /etc/passwd
root@vps-a71e1ee4:/# passwd debian
passwd: user 'debian' does not exist
root@vps-a71e1ee4:/#

16

I think, Daniel, that it’s a bug in the chroot program itself that comes with the rescue system, it’s not your fault.

First, try changing the root password directly.
passwd

(If it asks you for the new password, type it twice. If it works, you’ll have root access.)

If that fails, we can try changing our user’s password with chpasswd. This command is simpler and usually doesn’t give those errors. But first you need to know your username. Since you can’t use cat, try this:

ls /home

Most likely you’ll see a folder named debian, ubuntu, or similar; that would be your user.

echo 'debian:SecureNewPassword' | chpasswd

(Replace debian with the name you saw)

Exit the chroot and reboot.

exit
umount /mnt/sdb1

If none of these commands work inside the chroot, another option is to edit the /etc/shadow file manually, but it’s more complicated :confused:

Fingers crossed hehe
Sergio Turpín

17

the docker command works
well done, expert
the user was ubuntu
thanks a thousand times

here are the commands I ran

root@vps-a71e1ee4:/# passwd
New password:
Retype new password:
passwd: password updated successfully
root@vps-a71e1ee4:/#
root@vps-a71e1ee4:/#
root@vps-a71e1ee4:/#
root@vps-a71e1ee4:/# ls /home

thread 'main' (1196) panicked at /build/rust-coreutils-u5JpDp/rust-coreutils-0.8.0/rust-vendor/rustix/src/backend/linux_raw/param/auxv.rs:269:22:
called Result::unwrap() on an Err value: ()
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
Aborted ls --color=auto /home
root@vps-a71e1ee4:/# echo 'debian:xxxxxx' | chpasswd
chpasswd: (user debian) pam_chauthtok() failed, error:
Authentication token manipulation error
chpasswd: (line 1, user debian) password not changed
root@vps-a71e1ee4:/# echo 'ubuntu:xxxxxxx' | chpasswd
root@vps-a71e1ee4:/# exit
exit
[RESCUE] root@vps-a71e1ee4:~ $ umount /mnt/sdb1
[RESCUE] root@vps-a71e1ee4:~ $

PS C:\Users\Proprietaire>
PS C:\Users\Proprietaire>
PS C:\Users\Proprietaire> ssh ubuntu@92.222.67.200
ubuntu@92.222.67.200's password:
Welcome to Ubuntu 26.04 LTS (GNU/Linux 7.0.0-31-generic x86_64)

System information as of Mon Sep 14 13:03:32 UTC 2026

System load: 0.08
Usage of /: 89.1% of 37.65GB
Memory usage: 15%
Swap usage: 0%
Processes: 142
Users logged in: 0
IPv4 address for ens3: 92.222.67.200
IPv6 address for ens3: 2001:41d0:404:200::2d5d

=> / is using 89.1% of 37.65GB

  • Canonical Workshop gives developers fast, composable, reproducible, and
    secure developer environments that are perfect for agentic workflows.

    https://ubuntu.com/workshop

Expanded Security Maintenance for Applications is not enabled.

16 updates can be applied immediately.
To see these additional updates run: apt list --upgradable

Enable ESM Apps to receive additional future security updates.
See https://ubuntu.com/esm or run: sudo pro status

Last login: Wed Aug 26 04:55:16 2026 from 89.92.31.187
ubuntu@vps-a71e1ee4:~$

PS C:\Users\Proprietaire>
PS C:\Users\Proprietaire>
PS C:\Users\Proprietaire> ssh ubuntu@92.222.67.200
ubuntu@92.222.67.200's password:
Welcome to Ubuntu 26.04 LTS (GNU/Linux 7.0.0-31-generic x86_64)

System information as of Mon Sep 14 13:03:32 UTC 2026

System load: 0.08
Usage of /: 89.1% of 37.65GB
Memory usage: 15%
Swap usage: 0%
Processes: 142
Users logged in: 0
IPv4 address for ens3: 92.222.67.200
IPv6 address for ens3: 2001:41d0:404:200::2d5d

=> / is using 89.1% of 37.65GB

  • Canonical Workshop gives developers fast, composable, reproducible, and
    secure developer environments that are perfect for agentic workflows.

    https://ubuntu.com/workshop

Expanded Security Maintenance for Applications is not enabled.

16 updates can be applied immediately.
To see these additional updates run: apt list --upgradable

Enable ESM Apps to receive additional future security updates.
See https://ubuntu.com/esm or run: sudo pro status

Last login: Wed Aug 26 04:55:16 2026 from 89.92.31.187

ubuntu@vps-a71e1ee4:~$ docker --version
Docker version 29.7.2, build a7dcaa6
ubuntu@vps-a71e1ee4:~$