You are not logged in.
So when I was running Devuan 5 all of my devices (usb stick + external hard drive) would mount automatically when I plugged them in. Now with version 6 my external hard drive does not (usb stick still does though). It does show up in Mate's side pane, and when I click on it there, it gets mounted. So this is not too big of a deal, but I would still like it to mount when plugged in. I did a search and found this on the itsfoss website >Link Here< "Method 2: Automount Using Udev Rules and autofs" but it seems that there should be an easier simpler way to do this. Is there? Or should I just try the info from itsfoss?
Last edited by Ron (Yesterday 16:04:00)
Offline
Hi there, I guess the drive that isn't automounted is ext(x)-formatted, isn't it? Well, there is a new quirk in the udev rules from corporate actors inhibiting automount for ext(x)-partitions and others coming in with Trixie. Found that on the German Debian forum.
Check out for a file /usr/lib/udev/rules.d/64-ext4.rules, it reads:
# SPDX-License-Identifier: GPL-2.0-or-later
#
# Copyright (C) 2023 Oracle. All rights reserved.
# Author: Darrick J. Wong <djwong@kernel.org>
#
# Don't let udisks automount ext4 filesystems without even asking a user.
# This doesn't eliminate filesystems as an attack surface; it only prevents
# evil maid attacks when all sessions are locked.
#
# According to http://storaged.org/doc/udisks2-api/latest/udisks.8.html,
# supplying UDISKS_AUTO=0 here changes the HintAuto property of the block
# device abstraction to mean "do not automatically start" (e.g. mount).
SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="ext2|ext3|ext4|ext4dev|jbd", ENV{UDISKS_AUTO}="0"To override this rule you either change the "0" into a "1" with the risk that your change is overwritten from another update, or better write your own rule and save it to /etc/udev/rules.d/65-ext4.rules:
# extX-Dateisysteme automatisch mounten
SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="ext2|ext3|ext4|ext4dev|jbd", ENV{UDISKS_AUTO}="1" HTH
Last edited by rolfie (Yesterday 14:58:20)
Online
I don't have a /etc/udev/rules.d/65-ext4.rules file. Do I just create it?
I'm assuming a reboot will be necessary?
Offline
So I went ahead and just did it, and it works. Thanks rolfie. Now I have something new to add to my list of things to do after a reinstall. I really hate these things that "corporate actors" (to use your phrase) do trying to protect the user from himself. It sucks for those of us who have a clue of what we're doing.
Offline
Yes it sucks. In the meantime I have a long document describing all these tweaks.
BTW: yes you have to create that edit unter /etc yourself. To make it work, either reboot or try a:
# udevadm control –reload
# udevadm triggerLast edited by rolfie (Yesterday 15:41:43)
Online
I have a long document describing all these tweaks.
I might be interested in that.
Offline
I don't know what's going on, but now when I browse to /etc/udev/rules.d it shows the folder as completely empty. However, the fix still works. Any clue what's going on? (In the meantime I unmarked it as "SOLVED" even though it still is working.)
EDIT
I see what I did. I put the fix in /usr/lib/udev/rules.d and not /etc/udev/rules.d. But it's working. Should I leave well enough alone? Or will an update erase the file in /usr/lib/udev/rules.d?
Last edited by Ron (Yesterday 16:08:23)
Offline
I might be interested in that.
Well, its a LO document in German, and it contains one or the other more or less private comment I don't want to share. I am happy on helping here in the forum on topics I understand and have experience with.
Online
Well, its a LO document in German, and it contains one or the other more or less private comment I don't want to share.
I understand.
By the way, did you see what I did in my post directly above your post? I put the fix in the wrong place. Should I correct that or just leave it alone?
Offline
Well, what I got from the debianforum.de, the rules in /etc/udev/rules.d have higher priority. Don't know if that is true.
My preference would be to leave the system directory /usr/lib/udev/rules.d alone and save my tweaks in /etc/udev/rules.d, clear distinction. That also was the suggestion from a very experienced person that looked at the problem and suggested the fix.
Last edited by rolfie (Yesterday 16:22:36)
Online
Okay, so I deleted it in /usr/lib/udev/rules.d where I accidentally put it, and then put it in /etc/udev/rules.d where it should be. Rebooted and works (again). Remarked as "SOLVED." Thanks again rolfie.
[Maybe I don't have as much of a clue as I thought I did to put it in the wrong place.
]
Offline
I love it, nice work guys and thanks for posting, will add that to my list of post-install stuff for excalibur. ![]()
I won't post it here because memes are frowned upon, but made this yesterday after a conversation that was kind of similar took place on IRC: https://i.imgflip.com/adh3p8.jpg
https://sourceforge.net/projects/vuu-do/ New Vuu-do isos uploaded October 2025!
Vuu-do GNU/Linux, minimal Devuan-based Openbox and Mate systems to build on. Also a max version for OB.
Devuan 5 mate-mini iso, pure Devuan, 100% no-vuu-do.
Devuan 6 version also available for testing.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
Well, I was considering to write a bug report, but I did not do that because I am pretty sure it will be closed with the comment "works as specified".
Online