Automounting a new internal (SATA connected) SSD drive

[Daisuke]

I am a newbie running Linux Mint Cinnamon 19.2.

I have an NTFS formatted SSD drive which I need to mount as /media/daisuke/SSD2. This system has one user, myself! The drive should not be shared or accessible to a hacker. The application which has access to the drive runs with elevated privileges. I want to mount this drive automatically at startup.

I currently mount the drive using the Disks App manually each time I login. I realize I can mount the drive permanently using the Disks App, however the default mount point changes to /mnt/<UUID> where <UUID> is the UUID of the partition, and the options also change. I will return to this issue later in this post.

In researching this subject, I have found several suggested entries to /etc/fstab which will mount the drive on startup.
All methods require the existence of the /media/daisuke/SSD2, which I created using mkdir. The permissions on this directory are drwxrwxrwx. The current device is /dev/sdb1

The fstab columns are: <file system> <mount point> <type> <options> <dump> <pass> and a value for each column is required to automount the drive in the file system.

Method one is described a 2012 tutorial by fred, viewtopic.php?f=42&t=22093. The suggested fstab entry in fred's tutorial is:
/dev/sdb1 /media/daisuke/SSD2 ntfs defaults,umask=007,gid=46 0 0

Method two is one I am proposing. It was derived by examining the contents of /etc/fstab and /etc/mtab after using Disks to mount the drive for the current session. This entry would look like this:
UUID=1234567 /media/Daisuke/SSD2 fuseblk rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096 0 0

The reason I prefer method two is that the device (which is one partition) is uniquely identified. Also, with the options listed, the drive behaves as expected. I do not know the pros and cons of using ntfs, fuseblk or auto for the <type> of file system. Nor do I understand the ramifications of using group id 0 vs group id 46, or a umask of 007 vs rw permissions. Needless to say, there is also a whole heck of a lot about this arcana which I do not understand!!!!!

Going back to the Disks App method of creating a permanent mount point, I am not sure if it is recommended to simply edit the default values of the file system type (defaults to: auto), options (defaults to: nosuid,nodev,nofail,x-gvfs-show), and the mount point to the directory name required.

I hope one of the Linux Mint Cinnamon gurus who share their expertise here will have time to provide some guidance.

[rene]

the directory /media/<username>, in your case /media/daisuke, is sort of reserved for automounting removable media; it's not recommended to mount a permanently mounted FS under there.

You should second not use type "fuseblk" (in fact, you can't) and would be best to prefer explicit "ntfs-3g" over "ntfs": while they're apparently in fact the same these days, historically "ntfs" referred to a read-only kernel-based driver, whereas "ntfs-3g' did and does to the much preferred read-write user-space based driver.

What I tend to suggest for permanently mounted NTFS file systems is

Code: Select all

UUID=0123456789ABCDEF	/mnt/ssd2	ntfs-3g	noexec,fmask=133,dmask=022,uid=daisuke,gid=daisuke

[pbear]

FWIW, Daisuke, I don't think anyone on the Forum who knows how to edit fstab uses Disks for the purpose. Which isn't to say everyone sets up fstab the same way. There are many sound approaches and everyone has his or her preference. If you want to understand the subject, take a look at the man page, Ubuntu Help and this How-To Geek article. There are many articles, if you're interested.

IMHO, the most important thing is to make a backup before you start: sudo cp /etc/fstab /etc/fstab-old (or similar) will do it.

[rene]

Err, yes, good point: just edit /etc/fstab directly. To do so, navigate to /etc in your file-manager, rightclick -> "Open as root" or similar and in the new root-window that opens, doubleclick "fstab" to edit with your the normal, graphical editor. I.e., copy & paste in that line that I suggested or some version someone else may suggest and save the file.

[Daisuke]

Thank you pbear and rene for your advice! It is appreciated.

Unfortunately, I am not able to change the mount point. I discovered too late that by using Disks to mount what was planned as a permanent drive that the mount point would not be ideal in the larger scheme of the file system architecture. In the meantime, VMware has locked in that path and their tech support have discouraged me from changing it now. Since a Windows license headache will result from any changes, I have opted to live with the blemish. That said, I hope rene will provide more information about any downside risks to using /media as the base mount point beyond the fact that it is not in keeping with the FHS standards found here: http://www.pathname.com/fhs/pub/fhs-2.3.html

I would also like to mention that the above standards describes /mnt as a "mount point for a temporarily mounted filesystem." It also goes on the say that using subdirectories in /mnt (e.g. /mnt/daisuke) as mount points conflicts with an older tradition of using /mnt as a temporary mount point. If anyone knows of a published standard for naming the mount points for permanent, internal drives, this would be really useful to me and I think others since I have more permanent internal drives to mount and those I can do correctly.

The real purpose of my question was not to raise issues about what I name I assigned the mount point, but rather what the value of the <type> and <options> parameters are in fstab. I hope Rene will explain why fuseblk is not allowed and not recommended and why ntfs-3g is preferred over ntfs. Do these things make a difference to the software accessing the drive? And any light which can be shed on the pros and cons of various options would also be most helpful.

Although I am a newbie to Linux, I am a software engineer with some Solaris and a lot of Windows experience, although not as a system admin and not at the kernel level. Therefore, I hope to be able to learn more about the actual effect of the entries in the fstab as well as the best practices to use.

[rene]

As to downsides of using /media/<username>/<mountpoint>; first, I frankly needed to check whether or not /media/<username> exists on boot and before the user logs in in the first place. It does on current Ubuntu/Mint it seems, but having /media/<username> be a tmpfs (a ramdisk) or link to somewhere under the existing tmpfs location /run/user/<uid> would generally make some sense. Clearly if /media/<username> would not exist without <username> logged in /media/<username>/<mountpoint> would not be possible as a mountpoint for a permanently mounted filesystem, i.e., a filesystem mounted on boot before any user is around. Now that --- currently and on Ubuntu/Mint --- no such system's in place you may feel free to ignore this part in a practical sense.

Second, seeing as how /media/<username> is the system's per-user media-automount playground, connecting a say external USB drive with a filesystem labelled SSD2 would clash with your permanent mount: the media-automounter mounts on /media/<username>/<fsid> in which <fsid> is an fs-label if one is set on the fs, some fs-type specific (UU)ID if not. That clash is resolved by the media-automounter appending a digit if the mountpoint already exists but it would be confusing if nothing else. Though certainly one may feel free to also ignore this part if you nor anyone else would be connecting external USB drives with filesystems labelled SSD2.

I.e., practically speaking it's fine; just not very clean conceptually.

I wouldn't pay overly much attention to the FHS. It's a distribution-level document that aims to standardize things for the sake of other software; can be and widely is ignored by users. As oversight: /mnt started out life as a single temporary mountpoint, with e.g. /floppy for a removable floppy. After adding /cdrom and/or /zip and/or ... it was often decided that /mnt/floppy and so on were better locations. When automounting entered the picture some locations were transferred over to /media (the historic automounter needs an entire directory to manage all by itself) and eventually something like the FHS attempts to transfer all and restore /mnt to its single-temporary glory of old. Problem is that no one and including the FHS authors ever knew why so this didn't catch on everywhere.

FWIW, my personal system is to have machine-local, permanent mounts as a direct part of the filesystem. I.e., I put a local data-partition on /data, a local Windows one on /windows and so on. There's little conceptual difference with a potentially split-off /home or /boot; putting them in say /mnt would be the conceptual inconsistency. My /media is managed by the media-automounter only, /mnt/<mountpoint> I use for external mounts, with /mnt/tmp a location for a temporary mount. For both it and other mountpoints there, if a single one isn't enough, it's e.g. /mnt/tmp0, /mnt/tmp1, etc., with /mnt/tmp a symlink to /mnt/tmp0. In these systemd days /mnt/<mountpoint> also serves directly for (non-media/removable) automounts, on older systems /autofs did/does (as said, it needs/wants a directory to manage all by itself) with /mnt/<mountpoint> a symlink to /autofs/<mountpoint>; the /mnt locations are what they are accessed through.

Works for me...

You then ask why "fuseblk" is "not allowed". It's not so much that it's not allowed as that said type is "not real". FUSE is the (non-Linux specific) "Filesystem in userspace" framework, providing for filesystem implementation not in the kernel but as a semi-regular program in userspace. As architectural oversight, an application that read/writes a file does so by relaying requests to that end to the kernel, specifically to a part of the kernel known as the VFS, the Virtual Filesystem Switch. It in turn relays filesystem-type specific requests to filesystem-specific drivers further on down the kernel, i.e., the ext4, btrfs, etc., drivers. Also at that latter level exists the "fuseblk" driver but rather than read/write bytes from/to disk such as e.g. the ext4 driver it turns around and calls back out to FUSE in userspace, allowing it to service the request and just relay results back to the kernel-based "fuseblk" which it then passes back up again through the VFS to the requesting application.

As you can see from this it is not the kernel-based "fuseblk" driver that enforces any specific type. It's basically just a type-less shim, with FUSE in userspace doing any and all filesystem-type specific operations. That is, as far as the kernel and therefore the information it relays through e.g. the mount output and/or /proc/mounts is concerned, the filesystem doesn't have a type beyond "fuseblk" but that clearly doesn't mean that it also doesn't have one as far as the userspace FUSE is concerned. It needs to know what its dealing with; NTFS in this case.

Although these days and on Ubuntu/Mint tools such as mount.ntfs as called for mount -t ntfs are mere symlinks to mount.ntfs-3g the historic situation is as was explained with "ntfs" a somewhat poor read-only kernelspace NTFS driver (i.e., such as "ext4" in the above") and "ntfs-3g" the better, FUSE-based read-write userspace driver. We're not yet at the point where using just "ntfs" could not introduce confusion between the two; best to be explicit about using the FUSE driver, i.e., "ntfs-3g".

So, yes, again somewhat conceptual in this case, but the difference between actual "ntfs" and "ntfs-3g" would make a difference to software; with former you couldn't even write to the filesystem. It also pays to note that NTFS is not at heart a POSIX filesystem; does not use the to POSIX filesystems inherent owner and/or UNIX-permissions concept natively. An owner/group for the filesystem you make up at mount time and permissions you set/adjust through e.g. the fmask/dmask parameters that I showed so as to provide some semblance of sanity with NTFS in a UNIX environment. The shown parameters should have things behave relatively sanely for you.

I by the way rather doubt you could not change the mountpoint at this point due to licensing of a in a VM installed copy of Windows. Said mountpoint is specific to the host; where it shows up in the guest is configurable to wherever you want. But seems you're still the type to trust "tech support" so, well, whatever you say. Generally speaking, one of the first concepts to transition to when you go Linux is from that point on you being your own tech-support

TOO LONG!

[Daisuke]

Thank you rene for your comprehensive and deep reply! It seems that you work on kernel development for Linux so my hat is off to you!

In general, I rely on tech support when my efforts fail to produce a solution. On VMWare Workstation 15 , changing the pathname of a .vdmx file apparently requires the creation of a new VM and this in turn triggers Windows licensing issues even after the license belonging to the old VM has been released or freed by uninstalling the product key. I have observed this myself with a Windows 7 VM. There is no way to change the pathname in situ once an existing VM is up and running.

I will try to mount the file system with the following parameters: type, ntfs-3g as you recommend, and options: rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other and report back. I know these options differ from your suggestions but after some research, these are the ones I prefer. I will report back once I have had time to test this out and have a final set of options that provide the desired results!

[rene]

rw, relatime, allow_other and, given that root mounts the fs, user_id=0, group_id=0 seem to be default. "default_permissions" appears to be an old name for "permissions" and seems something you should be quite sure you in fact want; to be a setting that potentially interferes with access to files on the partition from within Windows. I don't use Windows and am not sure; this just as a possible heads-up.

"windows_names" might by the way also be desired; Linux will otherwise happily create filenames that for example CHKDSK stumbles over. All depends on usage...

[Daisuke]

I will have a closer look - thank you for the suggestions!

[Daisuke]

Thanks to everyone, especially rene, for the help I received here. I was able to successfully edit the /etc/fstab to have the new SSD drive mounted during system start-up and working as before when I made a temporary mount using the Disks app. I learned a lot more about file systems along the way.
This link also provided some helpful information as it has a complete list of mounting options for the ntfs-3g type file system.
http://manpages.ubuntu.com/manpages/bio ... 3g.8.html I especially liked the feature which lets you choose the version of Ubuntu which you are running, although in this case there were few differences that I could detect among various versions. Even so, since I am running Linux Mint Cinnamon 19.2 (Tina), I was glad to be able to refer to the documentation for Ubuntu 18.04 LTS (Bionic Beaver) on which Tina is based.

After carefully BACKING UP the original /etc/fstab file, I added these lines to the original file:
#SSD2 used by VMware for XP-ZIN VM vdmk file
UUID=12345ABCD /media/daisuke/SSD2 ntfs-3g uid=1000,gid=1000,relatime,permissions,allow_other 0 0

My heart was pounding as I restarted the system, wondering if this entry would bring about Armageddon. But my worst fears were not realized as the system actually booted, then I was able to see the drive in Nemo, check in a terminal that I was the owner and everyone had rwx permissions, and finally test the VM.

Note, the UUID above is not the actual UUID. My uid and gid are 1000 and it turned out that I did own the directory. But everyone has full access.
The device name of this drive is /dev/sdb1. I do not have this drive mounted on Windows at this time but when I finally get around to testing that, I will write back if I needed to make any mods.

One other point of interest is that when I look in either /etc/mtab or /proc/mounts, the mount point has been set to this:
/dev/sdb1 /media/gail/SSD2 fuseblk rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096 0 0
which is what the Disks app used and which sent me down this rabbit hole!

Once again, thanks to those who were so generous with their time. I hope this record will help others who follow.

[rene]

One note; the link you refer to is merely an online version of the documentation installed on your own system. If you type man nfts-3g into a terminal you have that same documentation shown to you. There's a man(ual) page installed for most of the lower level tools and/or systems available; man -k ntfs shows all that advertise having something to do with ntfs; man -k . would show all, period. yelp man:ntfs-3g for a GUI version.

[smurphos]

FWIW, my personal system is to have machine-local, permanent mounts as a direct part of the filesystem. I.e., I put a local data-partition on /data, a local Windows one on /windows and so on. There's little conceptual difference with a potentially split-off /home or /boot; putting them in say /mnt would be the conceptual inconsistency

Mmm, might be worth pointing out for new users that using non-standard mountpoints can lead to difficulties with for example Timeshift attempting to snapshot the contents of /data and /windows when it would ignore /mnt/data and /mnt/windows