Secondary NVME not automounting upon boot

My secondary NVME (WD_Black SN770) will not automount when booting. I am running LMDE 6 as my OS. I have to manually mount the drive, and it shows up as a removable drive. How do I correct this issue?

I’m not familiar with that Linux distribution, but it looks like it’s based on Debian. If so, you’ll have an /etc/fstab file, with one partition defined per line. Each line will have six parts, in the following order:

  • The partition identifier (name or UUID);
  • Where to mount it, such as / or /home;
  • Its type, such as ext4 or btrfs;
  • A set of comma-separated flags, with no spaces;
  • A probably-single-digit number, whose meaning I forget;
  • Another probably-single-digit number, whose meaning I also forget.

The important part for this purpose is the fourth item, the flags. Every partition listed in that file should be automatically mounted, unless it has the noauto flag in that list.

If there’s only one item in that list that has a noauto flag, then that’s likely your culprit. Removing that flag should solve the problem.

If there isn’t anything with a noauto flag, or there’s more than one, you’ll need to figure out which line refers to your secondary NVME drive. I haven’t found a straightforward way to do that; I usually use the GUI version of the Partition Editor (gparted) to see what the items are. It shows the physical drives in a pull-down menu at the upper-right, and you can usually identify them by their sizes or other characteristics.

If that isn’t enough to solve the problem, please post additional information (such as the contents of your /etc/fstab file) and we’ll see what we can do from there.

1 Like

as @Chad_Nelson already asked: can you show us your /etcfstab file? That’s where you configure the mounting of devices.

By default in Linux, removable devices will not be mounted automatically at boot, only when inserted into a running system can it ask to mount the drive.

Here is the /etc/fstab file:

#### Static Filesystem Table File
proc	/proc	proc	defaults	0	0
# /dev/nvme0n1p3
UUID=2eab2599-2959-4ef3-ae0f-6d467611f44a /  ext4 defaults 0 1
# /dev/nvme0n1p2
UUID=f29a21c4-cc90-4653-9fb3-5ddb59b37ded none   swap sw 0 0
# /dev/nvme0n1p1
UUID=9429-15AA /boot/efi  vfat defaults 0 1

The secondary NVME drive (/dev/nvme1n1) is not present. And as I said in the OP, when I mount it manually, it shows up as a removable drive.
I do have the UUID for this drive. Would modifying the fstab file fix this?

Yes, adding the right line to /etc/fstab will fix the problem. You should be safe copying the defaults 0 1 from your primary partition, and probably the ext4 part too.

Thanks @Chad_Nelson for the info.

1 Like

This is the same physical disk. Use blkid to show you the UUID of the secondary disk, and add it into the fstab.

Here is the updated fstab:

#### Static Filesystem Table File
proc	/proc	proc	defaults	0	0
# /dev/nvme0n1p3
UUID=2eab2599-2959-4ef3-ae0f-6d467611f44a /  ext4 defaults 0 1
# /dev/nvme0n1p2
UUID=f29a21c4-cc90-4653-9fb3-5ddb59b37ded none   swap sw 0 0
# /dev/nvme0n1p1
UUID=9429-15AA /boot/efi  vfat defaults 0 1
# /dev/nvme1n1
UUID=45dd43db-2aeb-40c4-9e06-75d9ec8aaa42 /  ext4 defaults 0 1

However, it is still using the old fstab file. How do I refresh this?
I have tried systemctl daemon-reload, which has not worked.
If I try to mount it, I get the error that says unable to find in fstab.
I’m at a loss of what to do.

I’m not sure if there are other problems, but the mount point you have there is /, i.e. the root directory. You already have a partition assigned to the root directory, so you’ll need to change that to another directory, which you will probably have to create manually.

This will not work. You try to mount the new drive as root “/” again - It will not reboot like this.
Where do you want to mount it? → /mnt/disk2 ?

@Jorg_Mertin what would be the syntax? I am in territory that I am not very familiar with.
The label for the drive is Data. Would it be something like:

# /dev/nvme1n1
UUID=45dd43db-2aeb-40c4-9e06-75d9ec8aaa42 /mnt/Data  ext4 defaults 0 1

Make it:

UUID=45dd43db-2aeb-40c4-9e06-75d9ec8aaa42 /mnt/Data  ext4 defaults 0 2

The 2 instead of the 1 at the end means, that in case of a file-system check, it can check disk 1 and 2 in parallel instead if checking them in sequence. And that’s perfect :slight_smile:

Great. Thanks for the help.

Edit: Warning: Bad practice below, see next post!

I too just learned how to do this, but I found that using “defaults” led to the drive being owned by root such that I could not modify or write any files to it without using sudo commands. So I did some searching and found that I should use this in place of “defaults”:


That worked for me, though I can’t exactly explain what each part of it means. Just in case you too run into this issue, otherwise disregard.

In fact, on a linux FS, you can, once mounted, change the ownership of the content. And that is permanent.

The umask you set actually gives the world write access to the device content which is very bad practice.
You can test it with:

~$ umask 0000
~$ touch bla
~$ ls -l bla
-rw-rw-rw- 1 foo adm 0 juin  18 11:53 bla
~$ umask 0002

The -rw-rw-rw- actually shows that the user, the group and world has the ability to write onto the content. Which is not good.

Here is what you should do.
Assume you are user foo and you want to have exclusive access to the content of the drive you mount under /mnt/data
In that case you mount the drive using the defaults - as mentioned previously.
Once the drive mounted, you elevate temporarily your privileges and give yourself access to the directory recursively with:

sudo chown foo /mnt/data -R

This command, will make you own the directory.
But, usually the directory, depending on the umask, will give user, group read, write, and execute access (execute on a directory means you can go inside. On a file, it means you can execute it if it is a valid binary, shellscript whatever.).

So, if you make a:

~$ ls -ld /mnt/data
drwxrwxr-x 16 foo adm 4096 mai   23 09:10 /mnt/data

you will see that user foo, group adm has full access to the directory, and world has execute (can go in) and read rights to it.
If you are on your own device, it usually is Ok.
If you want to make sure you are the only one to access the content of /mnt/data, issue a chmod command to remove accesses to the group and world with:

~$ chmod go-rwx /mnt/data -R
~$ ls -ld /mnt/data
drwx------ 16 foo adm 4096 mai   23 09:10 /opt

This will remove rwx (*read, Write and Execute) to all data and directories recursively under /mnt/data. Congrats, you now OWN your data :wink:

You can of course create your own group (family) and let other users (members of the group family for example) access the content. But that is not in the scope of this thread :slight_smile:


Wonderful explanation, thank you!

I considered chown-ing the mount point, but I wasn’t sure if I’d have to do that every time I booted. I think that’s how I ended up with the method I did. I’m also not very concerned with security, especially for this drive (it’s just inter-OS storage for things I want to work on in both OS’s which I’m booting from the main drive) so I may leave it as is, but I will certainly refrain from recommending it to others!

FW16 BIOS 3.0.3 fixes some bugs with the NVME slots, so if it does not work, try updating the BIOS and try again.