USB storage drives renaming on their own

Operating System ZimaOS
1

I have a new install of ZimaOS, and all is going well, except that I have a USB drive that whenever the server reboots it will have one name, 2TB, and after an hour or two, it will rename itself to 2TB-2. Any way to keep this from happening or to assign it a permanent name?

2

What’s happening (I believe):

  • Linux/ZimaOS auto-mounts USB drives.
  • If two drives share the same label (e.g. 2TB), or the USB re-enumerates after boot, ZimaOS avoids conflicts by renaming it to 2TB-2.

This is normal behavior, not a failing disk.

Best fix (I suggest): give the drive a unique label

From SSH:

lsblk -f

Find the USB partition (e.g. /dev/sdb1).

If ext4:

e2label /dev/sdb1 USB_2TB_BACKUP

If exFAT:

exfatlabel /dev/sdb1 USB_2TB_BACKUP

Reboot once. The name will stay stable.

Summary

  • -2 means label conflict or USB re-enumeration
  • Unique filesystem label = permanent name
  • No data loss risk

That’s the cleanest solution on ZimaOS.

3

Would this work on sata drives too?

4

I ended up plugging into a USB C port on the front of the Beelink EQR6. Apparently the USB 3 ports in the back tend to randomly drop and pick back up unless you tweak something in the BIOS. It’s ugly, but I don’t feel like taking it down plugging it into a monitor right now.

11 years daily driving Linux and I’ve never seen either of those *label commands before. Thank you for your response. I learned something

Jsg

5

Yes 100%.

This works on any drive type, SATA HDD/SSD, NVMe, USB because it’s changing the filesystem label, not the hardware.

So if your SATA drive is ext4:

e2label /dev/sdX1 MY_SATA_DRIVE

(Replace /dev/sdX1 with the correct partition.)

6

Nice one Jsg, that actually makes perfect sense.

If the rear USB3 ports are briefly dropping / re-enumerating, ZimaOS will often remount the disk and you’ll see the 2TB-2 behaviour. Moving it to the front USB-C port is a totally valid “don’t-touch-the-BIOS” fix.

And yep those label tools are old-school Linux gems:

  • e2label = ext4 label
  • exfatlabel = exFAT label

Glad it helped mate

1 Like
8

Hi, Fairly newby to ZimaOS. I’ve setup a DAS that sleeps every so often and its doing this same renaming thing, I’ve followed your previous steps but it appears this drive is not like what you’re describing. Within this image below could you explain to me how to keep this DAS-1/12.7tb drive from renaming itself to DAS-1-2/3/4 ETC. Its breaking my Jellyfin installation. Much thanks.
https://imgur.com/a/I60EY85

Couldn’t figure out how to add it directly rip

9

Hi, yeah this is a known behaviour, when your DAS sleeps/disconnects, ZimaOS re-detects it and assigns a new mount name (DAS-1-2, DAS-1-3, etc). That breaks anything relying on the path (like Jellyfin).

From your screenshot, your drive is:

  • Device: sdf3
  • Label: DAS1
  • Mount path changing: /DATA/.media/DAS1-3 etc

The fix is to stop relying on the label-based mount and instead mount it by UUID so it never changes.

Step 1 — get the UUID (confirm yours)

blkid /dev/sdf3

You’ll see something like:

UUID="B0A3B72A36B2E40" TYPE="ntfs"

Step 2 — create a stable mount point

mkdir -p /DATA/DAS1

Step 3 — mount using UUID (persistent + stable)

Edit fstab:

nano /etc/fstab

Add this line (replace with your UUID):

UUID=B0A3B72A36B2E40 /DATA/DAS1 ntfs defaults,nofail 0 0

Step 4 — apply it

mount -a

What this fixes

  • Path becomes stable > /DATA/DAS1
  • No more DAS-1-2 / DAS-1-3 renaming
  • Jellyfin won’t break anymore

Important note (root cause)

This happens because:

  • DAS sleeps > disconnects
  • Kernel reassigns device > CasaOS remounts with new name

If possible, also:

  • Disable DAS sleep (best fix)

But even if you can’t, the UUID mount above fully solves the renaming issue.

1 Like
10

unfortunately I am unable to currently stop the DAS from sleeping, Its giving nothing when I type “blkid” and when I attempt step 2 it tells me it cannot create the directory, Permission denied. Any insight?

11

Yeah that explains it, you’re hitting two separate ZimaOS quirks here:

1. blkid returning nothing

That usually means either:

  • the drive is currently asleep / not detected, or
  • you’re not running as root

First confirm the disk is actually visible:

lsblk

If you don’t see sdf3, the DAS is asleep → wake it up (browse it in Files or unplug/replug).

If you do see it, then run:

sudo blkid /dev/sdf3

2. Permission denied creating /DATA/DAS1

That’s expected on ZimaOS — /DATA is root-owned.

Just use sudo:

sudo mkdir -p /DATA/DAS1

3. Important (this is likely your real problem)

Because your DAS is sleeping, sometimes:

  • it comes back as a different device (sdf → sdg → sdh)
  • OR mounts under a new label (DAS1-2, DAS1-3)

So before doing fstab, confirm the device is stable:

lsblk -f

Look for:

  • your 12.7T NTFS drive
  • confirm the correct device name (don’t assume sdf3 every time)

If blkid STILL shows nothing

Run this instead (more reliable on ZimaOS):

lsblk -o NAME,FSTYPE,LABEL,UUID,MOUNTPOINT

That will show the UUID directly.

Reality check (important)

If the DAS keeps sleeping:

  • Linux sees it as a disconnect/reconnect
  • no mount method can fully stop that behavior

UUID mount will stop the renaming issue, but:

  • if the disk disappears completely, containers may still error until it wakes
12

Thanks very much for your detailed replies, Unfortunately after a ton of troubleshooting i’ve come to the conclusion I’ve fallen for the orico trap. This DAS is junk, I’ll be returning it to newegg and picking up a mediasonic Probox 4 which should provide the necessary ability to disable the sleep functionality.

13

Spot on, honestly that’s the right move.

Those Orico units are known for sleeping aggressively and reconnecting, which is exactly why you were getting the renaming and Jellyfin breaking.

The Mediasonic ProBox is much more stable. As long as you can disable sleep (or at least set a long timeout), you won’t see those issues anymore.

When you plug the new one in, just mount it by UUID straight away so the path stays fixed from day one.

Good call returning it, you would’ve kept chasing this forever.

1 Like
14

Yeah, Its really frustrating. I’ll take it as a learning experience, Don’t buy from newegg and don’t buy orico. The official software to disable the sleep function didn’t even work. :dotted_line_face:

15

Yeah I get it, that’s frustrating, but honestly we’ve all been there.

Best way going forward, before buying anything like this, just do a quick Google and check a few forums or Reddit threads. You’ll usually see straight away what people are saying, good or bad, and it gives you a pretty clear idea what to expect before you commit.

Orico especially pops up a lot with the same complaints you just hit, so you’re definitely not alone.

At least now you know what to look for, stable hardware + proper control over sleep.

1 Like