[1.6.2] USB mount point name truncated by one character after upgrade from 1.5.4 (deterministic, 25 → 24 chars)

Insight & Feedback
1

After upgrading a ZimaCube from ZimaOS 1.5.4 to 1.6.2 via the dashboard update button, the mount point of one USB disk was renamed — the last character of the name was dropped. The original mount point directory remained behind as an empty orphan.

This is not the _1 suffix issue fixed in 1.6.2. It appears to be a different regression in the same area, and it produces the same practical consequence: Docker bind mounts silently resolve to an empty directory.

Environment

  • Device: ZimaCube (Compatible: zimaos-zimacube)

  • Upgrade path: v1.5.4 → v1.6.2, via the dashboard update button

  • No RAID, no NFS

  • USB disk A: SanDisk SSD PLUS 1TB, ext4, /dev/sdb2, UUID 8ecf4664-b42e-410b-b4fb-3c2e6d440c7f

  • USB disk B: WD Elements 4TB, NTFS, /dev/sdc1, label Elements

  • One rclone (Dropbox) cloud mount

What happened

Mount point of the SanDisk disk, before and after the upgrade:

Before (1.5.4):  /media/sdb2-ata-SanDisk_SSD_PLUS     (25 characters)
After  (1.6.2):  /media/sdb2-ata-SanDisk_SSD_PLU      (24 characters)

The trailing S is gone. The disk itself mounts correctly and all data is intact — only the mount point name changed.

/media after the upgrade:

drwx------  1 root root     0  <user>_dropbox_<id>
drwxrwxrwx  1 root root  4096  Elements
drwxr-xr-x  8 root root  4096  sdb2-ata-SanDisk_SSD_PLU     <- actual mount
drwx------  2 root usb   4096  sdb2-ata-SanDisk_SSD_PLUS    <- orphan, dated pre-upgrade
lrwxrwxrwx  1 root root     5  ZimaOS-HD -> /DATA

The orphaned directory is empty apart from the udevil marker file:

$ sudo ls -la /media/sdb2-ata-SanDisk_SSD_PLUS/
total 8
drwx------ 2 root usb  4096 .
drwxr-xr-x 6 root root 4096 ..
-rw-r--r-- 1 root usb     0 .udevil-mount-point

The WD Elements disk (mount point name Elements, 8 characters) was not affected.

Key finding: the truncation is deterministic

I rebooted and compared. The truncated name is identical across boots — always sdb2-ata-SanDisk_SSD_PLU, never a different name, never an _1 suffix, and no additional directories are created.

The name went from exactly 25 characters to exactly 24 characters. Combined with the fact that it is fully reproducible rather than intermittent, this looks more like an off-by-one / buffer-length issue in mount point name generation than a race condition in USB enumeration.

It may be worth checking whether there is a 24-character limit being applied somewhere in the new mount point naming path introduced in 1.6.2.

Impact

The practical danger is silent failure in Docker bind mounts.

Docker does not fail when a bind mount source is missing — it creates an empty directory and mounts that instead. In my case, two containers (Jellyfin and Duplicati) bind mount /media/sdb2-ata-SanDisk_SSD_PLUS. After the upgrade, that path still existed as the empty orphan directory, so both containers would have started “successfully” while seeing an empty volume.

For a media server this is potentially destructive: an empty library can lead to items being marked as missing and metadata being cleaned up.

I had stopped both containers before upgrading, so nothing was affected. Users who do not stop their containers first will have them auto-start into the empty directory on the post-upgrade boot.

Workaround

Since the truncation is deterministic, a symlink from the old name to the new mount point restores container access without changing any container configuration:

bash

sudo rm /media/sdb2-ata-SanDisk_SSD_PLUS/.udevil-mount-point
sudo rmdir /media/sdb2-ata-SanDisk_SSD_PLUS
sudo ln -s /media/sdb2-ata-SanDisk_SSD_PLU /media/sdb2-ata-SanDisk_SSD_PLUS

Verified from inside the containers:

$ sudo docker exec jellyfin ls /pendrive
AppData  Documents  lost+found  Media  mnt

Note that this symlink will need to be removed before upgrading again, once the naming issue is fixed.

Other observations from the same upgrade

These are secondary and may be intentional, but I am noting them in case they are useful:

  1. The rclone cloud mount directory permissions changed from 755 to 700 (drwx------). Containers running as non-root would lose access to cloud mounts.

  2. The NTFS disk mount point ownership changed from usb:usb to root:root. Permissions remained 777, so access was not affected in my case.

  3. After the upgrade, the previously-good inactive slot is now reported as boot status: bad by rauc status. The old system is still in that slot. Is this expected behaviour after a successful update, or does it mean the previous version is no longer bootable via slot switching?

Diagnostic data available

I captured a full pre-upgrade snapshot (lsblk, blkid, findmnt, mount options, df, Docker bind mounts) and can compare it against the current state, so I can provide any additional before/after detail that would help. Happy to run specific commands or test a fix.

Best.