Install OpenMediaVault 8 on Debian 13: RAID 1 and SMB Setup

OpenMediaVault added 110 MiB of idle RAM and 3.3 seconds of boot time to a minimal Debian 13 VM, then refused our next SSH login. The package rewrites sshd_config so only root and a new _ssh group may log in, which locks out the user the Debian installer created. Plan for that before you install openmediavault on a remote box.

Original content from computingforgeeks.com - post 116212

This guide installs openmediavault 8 on Debian 13 from the official repository and takes the workbench from first login to a working NAS. That covers the admin password, the software RAID plugin, a two-disk RAID 1 mirror with ext4, a user, a shared folder and an SMB share mounted from a Linux client. Every command, screen and number comes from one Proxmox VM. The openmediavault ISO, which installs Debian and openmediavault in one pass, is the other route and is not covered here.

Benchmarked October 2026 on openmediavault 8.5.11 (Debian 13).

OpenMediaVault install cost, measured

Installing openmediavault pulled 174 packages and took just under five minutes, and the resident cost on a 2 GiB VM is small. The bigger change is in boot behaviour, because openmediavault adds its own console banner service and a network wait to every start. The table compares the same VM before and after the install.

Measurement	Debian 13 only	With openmediavault and RAID 1
Idle RAM used (MemTotal minus MemAvailable)	208 MiB	318 MiB
systemd-analyze boot time	3.86 s (1 boot)	7.16 / 7.19 / 7.35 s (3 boots)
Reboot command to workbench answering HTTP 200	not applicable	11.0 / 11.8 / 11.8 s
apt-get install openmediavault wall time	not applicable	4 min 55 s, 174 packages
RAID 1 initial resync, 2 x 10 GiB virtual disks	not applicable	102 s

Each number was taken the same way before and after the install, so the two columns compare directly:

• Idle RAM: MemTotal minus MemAvailable from /proc/meminfo, read three times 30 seconds apart once the VM had been up for at least 300 seconds, with no browser logged in to the workbench. All three reads agreed within 1 MiB.
• Boot time: the Startup finished line of systemd-analyze after a clean systemctl reboot. The Debian baseline is a single boot of the same VM before the package went in.
• Reboot to workbench: a timer started when systemctl reboot was sent and stopped at the first HTTP 200 from the workbench URL, polled once a second from another host.
• Resync: the gap between md: resync of RAID array md0 and md: md0: resync done in the kernel log.

The extra 110 MiB is the workbench stack: nginx, PHP-FPM, the omv-engined RPC daemon and Samba. That leaves 1.6 GiB of the VM free for page cache, so 2 GiB is a comfortable floor for a file server with a handful of users. The boot number roughly doubles, but systemd-analyze blame puts about 2.0 s of it on openmediavault-issue.service, which writes the console login banner, and up to 2.05 s on systemd-networkd-wait-online.service, so most of the added time is those two services. The install time depends mostly on your download mirror, because only 56 seconds of the 4 minutes 55 seconds was CPU time (46.8 s user, 9.8 s system).

Prerequisites

You need a fresh, minimal Debian 13 install with nothing on it but the SSH server and standard system utilities. openmediavault refuses to install when it detects a graphical desktop. The docs also say it overwrites the settings of every service it manages, so do not configure Samba, NFS, a web server or the network by hand beforehand. The lab used:

• NAS: nas01 at 10.0.1.50, a Proxmox VM with 2 vCPU, 2 GiB RAM, a 20 GB system disk and two empty 10 GB data disks, running the Debian 13 cloud image with kernel 6.12.
• Client: an Ubuntu 26.04 machine with smbclient and cifs-utils, used for the share test in Step 12.
• Access: a sudo user over SSH (klinsmann here) plus a console you can reach without SSH, such as the hypervisor console or a monitor and keyboard.

Treat that VM as a floor for following along, not a production recommendation. Size a file server by its disks first. Plan usable capacity for your data plus 20 to 30 percent free and a redundancy layout you can rebuild from; our RAID vs LVM vs ZFS comparison covers the trade-offs. Then add RAM for the page cache to hold the files people open most. openmediavault’s own documentation lists 1 GiB as the minimum and recommends 4 GiB for new administrators. Keep the system disk separate from the data disks, because openmediavault will not create shares on the disk it boots from.

On real hardware, the box and the drives matter more than any setting in this guide. If you are still choosing a platform, our DIY NAS build guide for TrueNAS, Unraid and mini PCs compares the hardware routes, and the NAS hard drives we recommend are the ones rated for always-on duty. A desktop drive that parks its heads every few seconds will wear out quickly behind a mirror that is read all day.

Prefer a single installer over a Debian install plus packages? The openmediavault ISO on the official download page lays down Debian and openmediavault together, and you can write it to a USB stick with Ventoy. Its installer erases the target disk and asks fewer questions, so it suits a dedicated box. After its first boot, continue at Step 5.

Step 1: Set up DNS before the package

openmediavault switches name resolution to systemd-resolved. If that package arrives as a dependency in the middle of the install, DNS stops working while apt still has packages to download, and the install fails half done. The openmediavault installation docs warn about exactly this, so install and enable the resolver first. The commands from here to Step 4 run as root, which is what the docs expect, so open a root shell:

sudo -i

Install the resolver and psmisc, then enable the service. On the Debian cloud image we used, systemd-resolved was already present and apt only confirmed it; a netinst system gets it fresh here:

apt-get update
apt-get install --yes systemd-resolved psmisc
systemctl enable --now systemd-resolved.service

Point the interface at your DNS server. Replace eth0 with your interface name from ip -br link (often ens18 or enp1s0 on real hardware), and 10.0.1.1 with your router or DNS server. This setting lasts only until the next reboot. After Step 4, a DHCP interface takes its DNS server from the lease; with a static address or a DHCP server that hands out no DNS, set the DNS server in omv-firstaid or under Network > Interfaces once the workbench is up:

resolvectl dns eth0 10.0.1.1

Confirm that the link now has a DNS server before you go on, because every later step downloads packages. A healthy result shows your server under DNS Servers and DNS in Current Scopes. If the server is missing and the address came from DHCP, the docs note that a running dhcpcd can override it before the install; stop it with killall dhcpcd and repeat the resolvectl dns line. That fallback only applies at this stage, because the openmediavault install removes the dhcpcd-base package.

resolvectl status eth0

With a DNS server listed on the link, apt can reach both the Debian mirror and the openmediavault repositories, which is all the next two steps need from the network.

Step 2: Add the openmediavault repository

Apt needs the openmediavault key in a keyring file before it will trust the signed repository. Install gnupg and wget, plus vim for the next file: a minimal Debian 13 install ships only vim-tiny, which answers to vi but not vim. Then fetch the key and convert it to the binary format that the signed-by option expects:

apt-get install --yes gnupg wget vim
wget --quiet --output-document=- https://packages.openmediavault.io/archive.key | gpg --dearmor --yes --output /usr/share/keyrings/openmediavault-archive-keyring.gpg

Create the repository file. synchrony is the codename of the openmediavault 8 series, which is the series built for Debian 13. The previous series, openmediavault 7, ran on Debian 12 and reached end of life in June 2026, so a Debian 12 box needs a distribution upgrade before it can take this repository:

vim /etc/apt/sources.list.d/openmediavault.list

Add these two lines, which point at the two official mirrors. The upstream example file also carries commented-out lines for SourceForge, the synchrony-proposed testing repository and the third-party partner repository, which you only need if you want those:

deb [signed-by=/usr/share/keyrings/openmediavault-archive-keyring.gpg] http://packages.openmediavault.org/public/ synchrony main
deb [signed-by=/usr/share/keyrings/openmediavault-archive-keyring.gpg] http://packages.openmediavault.io/ synchrony main

Refresh the package lists and ask apt which build it would install. The two mirrors were not in step on the day we installed, so this is worth a look:

apt-get update
apt-cache policy openmediavault

Ours listed a newer build on packages.openmediavault.org than on packages.openmediavault.io, and apt chose the newer one as the candidate, which is why keeping both lines is harmless:

openmediavault:
  Installed: (none)
  Candidate: 8.5.11-1
  Version table:
     8.5.11-1 500
        500 http://packages.openmediavault.org/public synchrony/main amd64 Packages
     8.1.1-1 500
        500 http://packages.openmediavault.io synchrony/main amd64 Packages

The Candidate line is the version Step 3 installs. Installed: (none) confirms nothing from openmediavault is on the box yet.

Step 3: Install openmediavault

Nothing in this install should ask a question. The environment variables stop debconf and apt-listchanges from asking questions, --no-install-recommends keeps the package set to what openmediavault needs, and the two DPkg::Options keep any existing config file instead of prompting about it. Run it from the same root shell:

export LANG=C.UTF-8
export DEBIAN_FRONTEND=noninteractive
export APT_LISTCHANGES_FRONTEND=none
apt-get update
apt-get --yes --auto-remove --show-upgraded \
    --allow-downgrades --allow-change-held-packages \
    --no-install-recommends \
    --option DPkg::Options::="--force-confdef" \
    --option DPkg::Options::="--force-confold" \
    install openmediavault

On our VM this took 4 minutes 55 seconds under time and installed 174 packages, Samba, nginx, PHP 8.4, Postfix and SaltStack among them. Postfix arrives disabled and inactive, so it sends nothing until you set up notifications in the workbench. The same transaction also removed packages: on our cloud image apt took out cloud-init, dhcpcd-base and systemd-timesyncd (openmediavault uses chrony for time), so a VM built from a cloud image stops applying cloud-init settings after this point. Check what landed:

dpkg -l openmediavault samba | tail -2

Both packages should show the ii state, which means installed and configured. Samba is pulled in by openmediavault itself, so its presence confirms the dependency chain resolved from the new repository:

ii  openmediavault 8.5.11-1                 all          openmediavault - The open network attached storage solution
ii  samba          2:4.22.11+dfsg-0+deb13u1 amd64        SMB/CIFS file, print, and login server for Unix

Do not close this session yet. The package has already rewritten the SSH server configuration, and these are the three lines that matter:

grep -E '^(AllowGroups|PermitRootLogin|AllowTcpForwarding)' /etc/ssh/sshd_config

Each of the three lines changes how you reach the box from now on:

• AllowGroups root _ssh: the lockout from the introduction. Any account outside _ssh is refused, including your installer user.
• PermitRootLogin yes: root stays as the fallback login the docs mention. Once your own user works, untick Permit root login under Services > SSH, save and apply. Make SSH changes there, not in sshd_config, because openmediavault writes that file from its own database.
• AllowTcpForwarding no: an ssh -L tunnel to the workbench connects, but every request through it fails with channel 2: open failed: administratively prohibited. Open the workbench over the LAN, or tick TCP forwarding (“Permit to do SSH tunneling”) under Services > SSH.

On the lab VM the command printed exactly these three lines, with no other AllowGroups or AllowUsers line in the file to override them:

AllowGroups root _ssh
PermitRootLogin yes
AllowTcpForwarding no

While you still have a root shell, add your own login user to the _ssh group. Replace klinsmann with the user you created in the Debian installer:

usermod -aG _ssh klinsmann

We tested both sides of this on the lab VM. With the user removed from _ssh, a new SSH login from another host failed with Permission denied (publickey,password), and after the usermod line the next login worked. Group membership is read at login, so the sessions already open are not affected either way. If you have already lost the session, Step 6 does the same fix from the workbench.

Step 4: Import and deploy the network settings

openmediavault keeps its own configuration database and generates system files from it. It has to learn the current network setup before it manages it, and omv-confdbadm populate imports the hostname, network, time zone and a few other settings that already exist on the system:

omv-confdbadm populate

The script list shows what it read. The docs say only /etc/network/interfaces is parsed, which is what a Debian netinst install uses, but our cloud image used netplan instead, and the 40netplan.sh script read that file:

Populating configuration database ...
Running script '20hostname.sh' ...
Running script '40interfaces.sh' ...
Running script '40netplan.sh' ...
Running script '50timezone.sh' ...
Running script '60nfs.sh' ...
Running script '70cpupower.sh' ...

Now write the network configuration the way openmediavault manages it. The address can change during this step, so run it from a console, or over SSH only if you can reach the console when the connection drops. If the network was not configured through /etc/network/interfaces and the populate step found nothing, run omv-firstaid instead and set the interface from its menu:

omv-salt deploy run systemd-networkd

A good Salt run ends with no failed states. On our VM it reported 15 states with 8 changes, and wrote 10-openmediavault-default.yaml and 20-openmediavault-eth0.yaml to /etc/netplan, next to the 50-cloud-init.yaml left behind by the removed cloud-init package. eth0 kept the same DHCP address and the DNS server from Step 1. An excerpt of the summary:

Summary for nas01
-------------
Succeeded: 15 (changed=8)
Failed:     0

We rebooted after this step and the address, DNS server and mounts all came back, with the workbench answering 13.5 seconds after the reboot command. Leave the root shell with exit. The remaining setup happens in the browser.

Step 5: Log in and change the admin password

The workbench listens on plain HTTP on port 80. Open http://10.0.1.50/ with your NAS address, and you get the login form below. The console banner on the VM prints the address and the defaults: user admin, password openmediavault.

Change that password first, because anyone on your network can read the default from the documentation. Go to Account > Password, enter the new password twice and click Save. The workbench confirms with “Updated password.” and the change applies at once, with no pending-changes banner:

This is the workbench administrator, which exists only inside openmediavault. It is not a Linux account and cannot log in over SSH. If you ever lose it, omv-firstaid on the console has a menu entry to reset it.

Step 6: Restore SSH for the installer user

Skip this step if you ran the usermod line in Step 3. If you closed that session first, the next login fails as below. We hit it on the lab VM, and the key was fine; the account was simply not in the _ssh group:

[email protected]: Permission denied (publickey,password).

Go to Users > Users, select the installer user (openmediavault lists it with a Debian tag), click the pencil icon and open the Groups list. Tick _ssh, close the list and click Save:

Unlike the password change, this edit only reaches the system after you apply it. A yellow “Pending configuration changes” banner appears at the top of the page; click its check mark and confirm. After the apply, id for our user showed _ssh in the group list, and SSH worked again. The same edit also changed the user’s primary group to users (GID 100), which is the group openmediavault uses for share access.

Every later form in the workbench works the same way: Save writes the openmediavault database, and nothing changes on the system until you click the check mark on that banner. If a change you saved seems to do nothing, an unapplied banner is the first thing to look for.

Step 7: Install the software RAID plugin

Software RAID is not part of the base install in openmediavault 8. The Storage menu has no Multiple Device page until you add the openmediavault-md plugin, even though mdadm itself is already installed. If you plan to use a single data disk, skip to Step 9. Go to System > Plugins, select openmediavault-md, and click the download icon:

Tick the checkbox in the confirmation dialog first, because the Yes button does nothing until you do. The plugin is 28.89 KiB, apt finished it within two seconds, and the install log window ended with “Restarting engine daemon …” and “END OF LINE”. On our next login the Multiple Device entry was listed under Storage.

Step 8: Build a RAID 1 mirror

A mirror writes every block to both disks, so you get the capacity of one disk and survive the loss of either. That is the right layout for two disks; with three or more, RAID 5 gives more capacity, and the comparison linked above explains when each level fits. The workbench offers Stripe, Mirror, RAID 10, RAID 5 and RAID 6.

Check the disks before you pick them, because the /dev/sdX names were not stable on our VM (the last section shows how they moved). Storage > Disks lists each disk with its model, serial number and size. Match the two empty data disks by size and serial, not by letter. The openmediavault docs recommend wiping a disk on that page before it joins an array, because mdadm works best with raw, unpartitioned devices; ours were new and empty.

Go to Storage > Multiple Device and click the + icon. Set Level to Mirror, select both data disks under Devices and click Save:

The array is created and starts its initial resync as soon as you save, before you apply anything. The banner still asks you to apply, so do it now; afterwards /etc/mdadm/mdadm.conf carried an ARRAY /dev/md0 line, which is what assembles the mirror at boot:

The resync of our two 10 GiB disks took 102 seconds, an average of about 105 MB/s on virtual disks backed by a ZFS pool. On real drives the time scales with capacity, so a pair of large hard drives takes hours. The array is usable while it resyncs, but it is not redundant until /proc/mdstat shows [UU] with no progress bar. Check the array once the resync is over:

sudo mdadm --detail /dev/md0

Both members should be active sync and the state clean, without the resyncing suffix it carries during the first sync. This excerpt was taken after a later reboot, so the member letters differ from the creation screenshot:

        Raid Level : raid1
        Array Size : 10476544 (9.99 GiB 10.73 GB)
      Raid Devices : 2
             State : clean
    Active Devices : 2
    Failed Devices : 0

    Number   Major   Minor   RaidDevice State
       0       8        0        0      active sync   /dev/sda
       1       8       32        1      active sync   /dev/sdc

If you prefer the command line for arrays, the same mdadm commands from our mdadm software RAID guide work here. The Multiple Device page lists every assembled array, including one built by hand, because the plugin reads the live md state. What a hand-built array can miss is its ARRAY line in /etc/mdadm/mdadm.conf, which is what assembles it at boot. Run omv-salt deploy run mdadm after creating one so openmediavault writes that file; on our VM the run finished with 6 states succeeded and left the existing ARRAY /dev/md0 line in place.

Step 9: Create and mount the file system

openmediavault shares folders, not disks, and every shared folder lives on a mounted file system. Go to Storage > File Systems, click the + icon (Create and mount a file system) and choose EXT4. The form offers BTRFS, EXT4, F2FS, JFS and XFS. ext4 is the default choice for a single mirror, because it needs no tuning and every Linux rescue disk can read it. Select the md0 device and click Save. A single-disk reader picks the data disk here instead:

openmediavault runs mke2fs in a log window and finishes with “END OF LINE”. On the 10 GiB mirror it wrote 2619136 4k blocks with 655360 inodes, directly on /dev/md0 with no partition table. Close the window, click the play icon (Mount an existing file system), select /dev/md0 [EXT4, 9.99 GiB] and save. Read that list before you save: ours also offered /dev/sr0 [ISO9660, 4.00 MiB], which is the cloud-init seed disk, not a data disk. Apply the change:

The row shows 9.72 GiB available and the status Available. On the NAS the file system is mounted under /srv/dev-disk-by-uuid-<uuid>, with user and group quotas enabled:

findmnt -t ext4

The second line is the mirror. The UUID in the path is what keeps the mount stable when disk letters change:

TARGET                                                       SOURCE    FSTYPE OPTIONS
/                                                            /dev/sda1 ext4   rw,relatime,discard,errors=remount-ro
└─/srv/dev-disk-by-uuid-1457cce3-477d-4132-975e-8b7aadbf61f2 /dev/md0  ext4   rw,relatime,quota,usrquota,grpquota

With the mirror mounted, the storage layer is finished. Everything after this point is users, folders and shares on top of that one file system, so a second mirror later only means repeating Steps 8 and 9 and pointing new shared folders at it.

Step 10: Create a user and a shared folder

Create share users in the workbench rather than with adduser over SSH, because openmediavault sets the Samba password only when the account password is set through Users > Users. Click the + icon, choose Create, and enter a name and password. We used nasuser. Leave Groups empty: every new account goes into users (GID 100), which is the group the default shared folder permissions give write access to.

After the apply, id nasuser showed uid=1001(nasuser) gid=100(users), and pdbedit -L listed it as a Samba user. Now create the folder. Go to Storage > Shared Folders, click +, name it data, select the md0 file system and keep the default permissions, “Administrator: read/write, Users: read/write, Others: read-only”:

That default produced drwxrwsr-x root users on disk, which is mode 2775 with the setgid bit, so files created inside inherit the users group. Select the data row and click Permissions. Set nasuser to Read/Write, save and apply:

The blue note on that page is worth taking literally: these privileges are what the SMB service uses to decide who may connect, and they do not touch file system permissions. A user needs both layers to write. Our OpenMediaVault SMB and NFS shares guide walks through the three “Permission denied” errors that come from mixing them up.

Step 11: Enable SMB and share the folder

After the install the SMB service is off, and a share saved while it is off is never served. Open Services > SMB/CIFS > Settings, tick Enabled at the top, leave the workgroup as WORKGROUP and click Save, then apply:

Switch to Services > SMB/CIFS > Shares and click +. Select the data shared folder, keep Public set to No so every connection needs a login, and leave Read-only unticked so the per-user privileges decide. Save and apply:

After the apply, smbd was active and listening on TCP 445 and 139. Print the share section that openmediavault generated to check that the privilege from Step 10 landed:

sudo testparm -s 2>/dev/null | sed -n '/\[data\]/,$p'

valid users and write list should both name nasuser, and the path should point into the mirror. If the user is missing, the privilege was saved but not applied:

[data]
	create mask = 0664
	directory mask = 0775
	force create mode = 0664
	force directory mode = 0775
	hide special files = Yes
	path = /srv/dev-disk-by-uuid-1457cce3-477d-4132-975e-8b7aadbf61f2/data/
	read only = No
	store dos attributes = No
	valid users = nasuser
	write list = nasuser

Do not edit /etc/samba/smb.conf by hand. openmediavault regenerates it on every apply, so a manual change lasts only until the next time anyone clicks the check mark. NFS exports, fstab entries on clients, Windows drive mapping and read-only users are covered in the shares guide linked in Step 10, so this guide stops at one working SMB share.

Step 12: Test the share from a client

A share is only proven once another machine has written to it. On the client, install the SMB tools. These are the Ubuntu and Debian package names; on Rocky Linux, AlmaLinux and Fedora the packages are samba-client and cifs-utils, although we only ran the client side on Ubuntu 26.04:

sudo apt-get install -y smbclient cifs-utils

List the shares the NAS offers to nasuser. This checks the password, the SMB service and the network path in one command, and it prompts for the password you set in Step 10:

smbclient -L //10.0.1.50 -U nasuser

A healthy result lists data and the IPC share. The “SMB1 disabled” line is expected: the old workgroup browse list needs SMB1, and the NAS does not offer it with the default SMB settings:

	Sharename       Type      Comment
	---------       ----      -------
	data            Disk
	IPC$            IPC       IPC Service (nas01 server)
SMB1 disabled -- no workgroup available

Mount it once to prove a write works. Our test used a root-only credentials file (/root/.smb-nas01, mode 600, holding username=nasuser and password= lines) so the password stays out of shell history:

sudo mkdir -p /mnt/nas-data
sudo mount -t cifs //10.0.1.50/data /mnt/nas-data -o credentials=/root/.smb-nas01,uid=$(id -u),gid=$(id -g)

findmnt -t cifs showed vers=3.1.1 and username=nasuser on our client. Persistent fstab entries, NFS mounts and the permission errors you can hit are covered step by step in the shares guide linked in Step 10, so this test stops at one write.

Write a file from the client. The date stamp makes it easy to tell this test file from any later one when you check the NAS side:

echo "written from client $(date -u +%FT%TZ)" > /mnt/nas-data/hello-from-client.txt

On the NAS, the file sits on the mirror and belongs to nasuser with the users group, not to the client’s local account. That is the mapping you want, because a file written over SMB by one user stays editable by every other member of users:

ls -l /srv/dev-disk-by-uuid-*/data/

On our NAS, the 41-byte file showed exactly that ownership, with mode 664 from the share’s create mask:

total 4
-rw-rw-r-- 1 nasuser users 41 Oct 18 02:37 hello-from-client.txt

This is the checkpoint for the core setup. The terminal capture below shows the package versions, the clean mirror and the three services the workbench depends on, all from the NAS:

The dashboard starts empty on a fresh install. Click the settings page link on it and enable the widgets you want; we turned on System Information, Memory, CPU Utilization, MD Devices, File Systems and Services. It then shows the mirror state and the running services at a glance:

Our Memory widget showed about 340 MiB (17 percent) used a minute after a boot. It is a different reading from the 318 MiB in the first table, which was taken as MemTotal minus MemAvailable after five minutes of uptime, so compare like with like when you size a small box.

Why disk names changed on every reboot

The /dev/sdX letters on our VM moved between boots, which is normal Linux behaviour and the reason openmediavault never uses them for mounts. The VM had three SCSI disks, attached as scsi0 (system), scsi1 and scsi2 (data). Each boot named them differently:

Boot	System disk	Mirror members
Before openmediavault	/dev/sda	/dev/sdb, /dev/sdc
Boot on which the RAID was created	/dev/sdc	/dev/sda, /dev/sdb
Timed reboot 1	/dev/sda	/dev/sdb, /dev/sdc
Reboot after the network deploy	/dev/sdb	/dev/sda, /dev/sdc

Linux probes the disks in parallel, so the letters follow whichever disk answers first. Nothing broke, because the mirror is assembled from the md superblocks on its members and the file system is mounted by UUID under /srv/dev-disk-by-uuid-.... Every boot after the mirror existed came up with [UU] and the same mount path.

The risk is human. A wipe, a dd or an mdadm --zero-superblock typed against a letter you read on a previous boot can hit the wrong disk, including the system disk. Before any destructive step on the NAS, run through these checks:

1. Read the serial number of the disk you mean on Storage > Disks, or with lsblk -o NAME,SIZE,SERIAL on the console.
2. Match it to the current /dev/sdX letter on this boot, not one you noted earlier.
3. Use the /dev/disk/by-id/ path in the command, which carries the serial and never moves.

That habit costs a few seconds, and it is the difference between replacing a failed mirror member and erasing the healthy one.