Ensure the NVMe device retains its name across reboots and mount it automatically using Veracrypt.
Ensure the NVMe device retains its name across reboots and mount it automatically using Veracrypt.
Hello, ensuring a consistent NVMES drive name involves setting the correct mount point permanently. On Linux Mint 22, you can use UUIDs to lock the device name. Adjust your UUID rules in /etc/udev/rules.d/01-nvme.rules to prevent switching between /dev/nvme0n1 and /dev/nvme1n1.
how do you explain this? every filesystem needs a unique identifier. look in /dev/disk/by-uuid/ or use udevadm info on the partition. without a UUID it might not be properly formatted or unpartitioned. https://wiki.archlinux.org/title/VeraCry...c/crypttab as for your question, likely the problem is using the full path instead of just the device name you need, like SYMLINK+="nvme0n1". You might also be missing parameters such as SUBSYSTEM and KERNEL. check the relevant wiki links for more details.
Partition is secured with veracrypt, compatible across Windows and Linux, and functions when mounted. Currently I test by attempting to mount both, it succeeds temporarily. However, I must wait about 90 seconds if one fails—either via crypttab or fstab. Then I add entries to fstab for persistent use. The documentation isn’t very clear; I think the expected format should match: KERNEL=="nvme[0-9]n1", SUBSYSTEM=="block", ATTRS{id_serial}=="Samsung_SSD_970_EVO_2TB_S69ENF0WXXXXXP_1", SYMLINK+="nvme0n1".
Sure, just to clarify, you want to create a symlink pointing to a partition rather than the drive directly. Even though the names match, they should be treated as separate devices. For partition 5, I recommend using KERNEL="nvme[0-9]n1p5" and setting the symlink to nvme0n1p5. I don’t have a system to test this yet.
The PARTUUID belongs to the GPT table that specifies the disk layout. It won’t include the filesystem UUID yet, which becomes available after decryption. You can add partition labels within the GPT file as well; running blkid will provide both the UUIDs. Check /dev/disk/by-partuuid/[your_partUUID] to see a symlink pointing to the correct node. I haven’t used crypttab, but it should work as a replacement for either "/dev/nvme0n1p5" or "/dev/nvme1n1p5". You can also label the partition and reference it via /dev/disk/by-label/MyCrytptPart. Remember, symlinks to disk entries are relative, so you might need a udev rule to create absolute links. This GPT table definition outlines partition details but excludes encryption, leaving UniquePartitionGUID and PartitionName outside the encrypted section.
Everyone, the solution is working now. I initially tried the first approach and found the encrypted partition (nvme0n1). Using udevadm info helped me locate the disk ID with the name /dev/nvme0n1. I extracted the relevant lines containing "by-id" and copied everything after "/nvme-" followed by "_1".
For the second drive, nvme1n1, I created matching rules in udev and updated the crypttab with Veracrypt settings. In the GUI, I set up a file with my password for the VeraCrypt partition and stored it on a LUKS encrypted root volume containing only the password. I added this entry to /etc/fstab using a line like:
/system/drive/my_partition /mnt/nvme0n1 ntfs nosuid,nodev,nofail,noauto,x-gvfs-show 0 0
Currently, no apps can access the mounted folder because it's protected by NX Windows sync. I manually opened it once with File Explorer.
P.S.: I didn’t modify files directly from the command line; instead, I used a text editor in double commander with root privileges.
As a brief note: /dev/nvme{0,1} exists without a manual link before manual creation isn't a symlink—it's a real device node. For persistent naming at boot, use unique identifier filters with ACTION=="add" and repeat for each hardware item. If you're dynamically managing devices and insist on stable names, prefer SYMLINK+=. However, if you're relying on the kernel to assign names automatically, opt for absolute paths like "/dev/My2020SamsungDrivesEncryptedPartition". If hardware changes unpredictably, naming rules are more reliable.