[O/S] How to mount a secondary drive at startup?

[Martek]

I've been all round the houses trying different distros but have ended up coming back to Debian as the "keeper". I have a secondary drive in my PC which on other distros I went into the Disks app and then the mount options clicking off User Session Defaults, making sure Mount at system startup is selected and setting the mount point. This worked fine in other distros but in Debian on bootup I still have to enter the admin password when I first try and access it.

How do I have the drive accessible at startup without requiring any further interaction to access it?

[bw123]

There are several ways to do this,

For a "...drive in my PC..." that is always present I prefer fstab.
https://wiki.debian.org/fstab

Be careful, it's important that fstab is correct, or your system won't boot.
the fstab file is important to your system backup strategy.

If you are using kde, then there is also a helpful dialog in system settings> removable devices that is pretty flexible.

It's an oddly worded question, it sounds like you are on gnome and saying that Disks app in debian behaves differently?

Do some searches, it's a very common question.

Good Luck,
bw

[Martek]

There are several ways to do this,

For a "...drive in my PC..." that is always present I prefer fstab.
https://wiki.debian.org/fstab

Be careful, it's important that fstab is correct, or your system won't boot.
the fstab file is important to your system backup strategy.

If you are using kde, then there is also a helpful dialog in system settings> removable devices that is pretty flexible.

It's an oddly worded question, it sounds like you are on gnome and saying that Disks app in debian behaves differently?

Do some searches, it's a very common question.

Good Luck,
bw

Yes I'm using the Disks app in Gnome and yes it is behaving differently to the same app on Ubuntu, Fedora and Zorin.

[bw123]

A disk partition can be mounted, and still require auth if you are not the owner of the resource you want to access.

It sounds like maybe you want to research ownership, not mounting. Check what partitions are mounted when you boot from a terminal like this:

Code: Select all

$ mount
$ findmnt

If you confirm that the partition is not mounted after booting when gnome-disk-utility says it should be, you could pursue a bug report.

Show people on the forum here the output of the mount command? Someone might be able to help if you showed the settings in the Disks app, with a small attached screenshot.

The topic might attract better response if you added, "[O/S] How to mount... using gnome-disk-utility (Disks)"
Thanks,
bw

[Dai_trying]

I have noticed that when mounting a new device using thunar that it is mounted under /media/<user>/<mountpoint> and is owned by root, to make the device (or partition) usable by normal user I have to change ownership of this mount point. I typically use the following

Code: Select all

sudo chown $USER:$USER /media/$USER/<mountpoint>

Just place the actual mount-point name in place of "<mountpoint>" in the above command (HINT: tab completion usually finds this easily). This is only needed once for any given device/partition.

[pbear]

How do I have the drive accessible at startup without requiring any further interaction to access it?

Are you willing to learn how to do this yourself, by editing fstab? There's a learning curve, but it's not rocket surgery. Meanwhile, Disks is notoriously obtuse in how it sets mount parameters. FWIW, I love the app, indeed have it on Panel and usually opened. Disks does many things well. Editing fstab isn't one of them (imho). For comparison, here's what my data partition mount looks like:

Code: Select all

LABEL=Data-Files   /data/files   ext4   noatime,nofail   0   2

Pretty simple, eh? Mounting an NTFS partition is a bit more complicated, and Disks messes that up even worse (again, imho).

... I have to change ownership of this mount point ...

FWIW, what you're actually changing is ownership of the file system. If you change ownership of the mount point without the file system mounted, you'll find it has no effect. Yeah, I was surprised too. Lots of sources say what you did. I did lots of tests, though, when writing a data partition tutorial a few years ago for another Linux forum. Goes the other way also, by the way. You can't restrict access by setting ownership of the mount point either.

[sunrat]

I have always successfully used

Code: Select all

LABEL=Music      /mnt/music      ext4         auto,user,rw,noatime   0    0

this is an internal partition so doesn't need nofail, it's always there. I do change the mount point permissions to be owned by user, maybe that doesn't matter as pbear suggests.

[Dai_trying]

... I have to change ownership of this mount point ...

FWIW, what you're actually changing is ownership of the file system. If you change ownership of the mount point without the file system mounted, you'll find it has no effect. Yeah, I was surprised too. Lots of sources say what you did. I did lots of tests, though, when writing a data partition tutorial a few years ago for another Linux forum. Goes the other way also, by the way. You can't restrict access by setting ownership of the mount point either.

I have done this a lot of times and it does indeed work! although I have not tried it without the system being mounted which may have no effect as you say, but then again the mount point would not even show in /media/$USER when the device/partition is not mounted and so would be an impossible (or not "normal") situation.

EDIT: Just to add that I read this post originally as mounting a device using a file manager (ie thunar) as opposed to mounting using fstab which may have a different outcome as the mount-point must(?) exist in order for it to be mounted. Looks like I may have misunderstood the original intent.

[pbear]

Ahem, /media/$USER is a mount point. And, of course, already owned by you before running chown. One other tidbit. On a multi-user system, there's nothing you can do permissions-wise, mount point or file system, to enable other users to access your /media/$USER (or you theirs). It's a hard-coded access restriction. For a USB drive to be shared (e.g., for backups), it must be mounted somewhere else, e.g., /media/backups.

[Dai_trying]

Ahem, /media/$USER is a mount point. And, of course, already owned by you before running chown. One other tidbit. On a multi-user system, there's nothing you can do permissions-wise, mount point or file system, to enable other users to access your /media/$USER (or you theirs). It's a hard-coded access restriction. For a USB drive to be shared (e.g., for backups), it must be mounted somewhere else, e.g., /media/backups.

Your comments contradict my experience, enough said I think.

[CwF]

There are a few factors here we're typing right past. I'd think the OP's issue with a required password is a procedure issue and not a mount point or device permission issue. If gio mount or udisk2 precedure does not have permission to create the mount, it therefore does it without user credentials. The error is here in the procedure.

I'm not gnome DE fluent, and I use systemd as I've documented under Xfce. Conventional mounting in my Xfce's does still work and conflicts with my chosen method so I hide partitions with udev to avoid potential parrallel mounting with both methods. If I do allow the default Xfce DE method devices are correctly mounted in /mnt/$user/label with normal permission to the user regardless of device permissions. Polkit grants user permissions in both cases. Sytemd-mount will mount in /run/user/somewhere when where is not specified, I only specify mount points within ~/.

I think some in implementations the mount procedure is being called as root. Permissions should be established within the mount procedure itself with gui and uid modifications according to which user invoked the procedure. If additional permission tweaking is needed the this mount procedure was done wrong! I haven't kept track of the many ways to screw it up. When the mount prodcedure is done on behalf of the user it works, when the procedure is done as root it fails for the user. With most methods the mount point does not need to preexist, it may.

If the mount is by user 1000 with permission to do so and the disc is 0:0 (root owner:root group) or any other, then 1000 can read everything, write new as 1000. Further permissions are inherited from the location. If within user space then this user can delete non-1000 files, if mounted in root space then 1000 cannot delete those same files on that same device. /mnt/$user/*, /run/$user/*, and /usr/local/bin/* are special cases with additionally enforced permissions.

It is my incompletely tested opinion that /mnt/? permissions should never need modified manually. But with 7 additional devices mounted in my current cluster and /mnt is empty so what do I know!

And yes, these conflicting methods and outcomes is exactly why I do it the way I do. I'd recommend learning how systemd-mount works. Even though there are still some bugs with thunar, I'm resigned to the this new way. Out with the old...

@Martek I can only suggest Gnome may have an incomplete polkit setup and worthy of a bug report. I would try using a terminal for feedback. Invoke whatever gui utility you're using as user in that terminal and try to determine what is being used for permission to mount. If polkit, then the bug is that the end-user needs to add a polkit rule for permission as user. This seems the case with Xfce also, but I haven't tested a fresh install but in the past polkit action has been flakey and user+password is as root while user+rule as user. It may be the case that other distros are properly setting up polkit for the user, and Debian doesn't. If the device is reliably always there, then the fstab approach is the most direct.

[pbear]

Bear in mind, Dai_trying, I didn't say what you're doing doesn't work. I said it works for a different reason from the one stated. Whether the distinction is relevant to the OP's problem remains to be seen.

[Martek]

I have used fstab now to add it. In all honesty, I'm not really a command line and config file person so I have no idea if it is setup correctly. I prefer GUI which is why I was always trying to do it through the Disks app.

I think this is thing. I'm not sure Linux is really intended for me. I hate having to touch command lines or config files.

[bw123]

...
I think this is thing. I'm not sure Linux is really intended for me. I hate having to touch command lines or config files.

It's okay, most people will understand. I notice more than a few posts today expressing your frustration. Maybe this is a good time for you to slow down, read a little, and think it over. If the scrollwheel is bugging you, then put on some music, get a piece of chocolate, and relax.

https://linux.oneandoneis2.org/LNW.htm

[pbear]

I hate having to touch command lines or config files.

Your choice obviously. As my mother used to say, there's a reason they make more than one flavor of ice cream.

Part of the problem with Disks-for-fstab is that the GUI is illusory. Yeah, you can use a mouse, but the part which really matters is the text you put in the various boxes. That text is the same code you would use if editing fstab manually. Putting a pretty wrapper on it doesn't make the substance any easier. The developers made some one-size-fits-most guesses for the defaults; sometimes they work, sometimes not.

Anyhoo, you've tried. If Linux doesn't work for you, move on. If you want to play with it on the side, consider installing a virtual machine in VirtualBox (an app you can install in Windows).

[arzgi]

gpm is still in stable's repo