SSD mounting point issue on Jetson Xavier NX

The SSD I’m using is supposed to automount in /media/backup_drive after login. Fifteen seconds after login, I start to save files to /media/backup_drive . When I first tried this it successfully saved files to the SSD. However, it has now created a directory called /media/backup_drive on the main memory of the Jetson and the directory the SSD is mounted to is remapped to /media/backup_drive1 .

When I changed the script that saves the files to save to /media/backup_drive1 it worked for a few day and then the same issue occurred. the SSD mounted in /media/backup_drive2 and /media/backup_drive1 was created on the main memory.

Is there a way to fix this remapping issue?

PS: I’m using a Micron 1100 2TB SATA 6Gb/s SSD on a Jetson Xavier NX.

This is normal behavior unless you’ve specified a desired behavior. I will caution you in what follows that if you set up in the most simple way to force a particular mount point, then a lack of the SSD being present will cause boot to halt until the SSD is present. You will want to set this up in steps.

Since automount of per user removable media goes to “/media”, I’ll suggest that you should perhaps mount this elsewhere if and only if the same device is to be used in the same way every time. If the end user is going to sometimes use different drives or media, then you probably do want to keep it in “/media”. However, if only one user is using this, then perhaps a better location would be “~/ssd/”, or if the system is always going to have this device, and multiple users will access this, then perhaps at “/usr/local/mnt/media”. It is up to you, but my example will use “/mnt/ssd” (for no particular reason, other than it is a mount location, but don’t forget to “sudo mkdir /mnt/ssd” first).

In the file “/etc/fstab” you can set up exact mount instructions. Those instructions can be for either the device name (e.g., “/dev/sda1” is the first SATA device partition), or it can be via the UUID of the partition (the PUID). How do you identify the disk? Is it a USB device? Does it use an m.2 slot? What identifier do you see for this device?

Incidentally, if the disk is connected to the Jetson, then this command will be useful in seeing devices, partitions, and identifiers:
lsblk -f

Note that the “mmcblk0p1” partition is the only eMMC partition you will care about. This is the rootfs and you won’t touch it, but you will perhaps find it of interest to note it has a UUID and is formatted for ext4 filesystem type. Your media will have similar information for the partition in question.

Let’s pretend you use “/dev/sda1”, and that it is formatted as ext4. A valid /etc/fstab entry where it is optional to not have this device, and mount is still manual, is this:

/dev/sda1    /mnt/ssd      ext4    noauto,user     1 2

(note that you can use as many spaces or tabs to separate tokens as you want…this is useful for clarity in an fstab file with lots of entries)

The “noauto” is used so that specifications exist, but mount will not be automatically attempted. If at any point you ran this command though, then mount point and details would be properly set up without you needing to enter them (this is a useful start because it allows you to test before comitting):
sudo mount /dev/sda1 (notice that there is no mount point listed)
sudo mount /mnt/ssd (notice that no device name is mentioned)
…both of the above would mount as ext4 to “/mnt/ssd” using "/dev/sda1.

The “owner” (or as another option, the “user”) is simply about ownership of the content. Once you have this done, if you have questions on permissions, then you can ask further.

The two numbers at the end are related to whether to backup when using backup software (field 5), and the order of filesystem check if something needs fixing.

The root filesystem is always the first to filesystem check if something went wrong, and so it has field 6 as “1”. Your device will use “2” because the rootfs is mounted first, and this device mounts on the rootfs.

You could use “0” in the 5th field if you don’t want it to be backed up during a normal backup. In reality I doubt anyone has regular backup software running daily or hourly or in any way at all, and so a “1” won’t do anything in those cases. If you don’t dump the filesystem, then enabling dump to see the device will do exactly nothing.

Now if you happen to have this specific partition, say “/dev/sda1” or “/dev/mmcblk1p5” with a partition UID, then you could use this as the identifier. The result would be that no matter how many devices you might plug in, the mount point would only care if that exact ID were inserted. Everything else would still use its default “/media” rules. As an example, if the UID of the partition were “1234-abcd-5678”, then the fstab line could be altered like this:

UUID=1234-abcd-5678     /mnt/ssd      ext4    noauto,user     1 2

There are also possible “labels”, which are similar to a UUID or partition UID, but may not be unique. Unless you have an interest in having several disks which might be interchangeable (e.g., a backup rootfs filesytem), then you won’t use the “LABEL=”.

During boot, if you have a rootfs fail to mount, then you really must stop boot. However, for an optional partition, the option “nofail” implies a failure will continue booting and not halt. If you are sure your disk mounts correctly from manual testing, then you can remove the “noauto” and use mostly “defaults”. The “defaults” option (we are talking about the 4th field) is equivalent to this comma delimited list:
…allowing for failure, but auto mounting, is this edit to the 4th field:

If using the “/dev/sda1” as an identifier, and if you know you want auto mounting, but sometimes the disk won’t be present, then it leads to this line in “/etc/fstab”:

/dev/sda1    /mnt/ssd      ext4    rw,suid,dev,exec,auto,nouser,async,nofail     1 2

This above line, edited for your device or UUID, is how you’ll probably want to use the device. There might be some permission changes you are interested in for the mount point (via chmod or maybe via fstab options).

FYI, if you are certain the disk will always be there, then you could either leave out “nofail”, or replace that entire 4th field with “defaults”.