I changed nothing, but yesterday & today when I click a drive, it askes my for the root password, no big deal. I just have no idea how that option is on noew. I didn’t even know that was a option.
2 Likes
Look at this https://forum.manjaro.org/t/stable-update-2024-01-13-kernels-systemd-qt5-mesa-dbus-firefox-thunderbird/155007/123
1 Like
From what I have gathered the manjaro-hotfixes package contained a couple of udev rules to ensure a stable function within storage and wheel related to bluetooth - and a specific version of bluetooth - the blueman.
udev rules for storage
The storage group should never be assigned to any user, as the group as unfettered access to any, all and everying - no matter the user or the ownership implemented.
wheel rules
The rules dates back to 2019 - it is likely the blueman defaults has been updated. Don’t change unless you can make an explicit determination that blueman requires wheel aka superuser permissions.
The best path ongoing
storage
You need to figure out why being a member of *storage group is required for your usecase - perhaps you got used to insufficient permissions - thus the storage group is the big hammer solving all problem.
blueman
As the rule added permisions to blueman bluetooth devices - the best thing is to figure out why wheel is needed or better - why it is not needed. Perhaps you are sharing a device using bluetooth - thus wheel is the big hammer.,
The second best
If you are not able to figure out why any of these groups is required - but - yet they are solving a problem we did not know we have.
storage
As stated above - you should not need this but you can add it to current user - presumed the initial Manjaro Linux User on a single user system
sudo gpasswd -a $USER storage
blueman
There is no second best for this one.
The wheel is default for the first user when you install Manjaro - no action need to be taken - unless the it involves non default users.
No matter the system the bluetooth stack runs on user-space - so technically you don’t need to elevate permissions to access device, configure a bluetooth network or change state - perhaps saving the configuration - it is stored /etc/bluetooth.
You should not need this - Gnome shell possibley handles the permissions on it’s own.
I don’t have any answers, but am just trying to learn more. Could you clarify what you mean when you say “drive is in system”. Do you mean, for example, that the drive is listed in /etc/fstab? Also, what is the file system on the drive (ext4, ntfs, etc.)?
I noticed this too since a couple days
Hi,
I know from the numerous posts you made here since all the years that you are really trying to help.
And so do I, even if I only posted a few problems I had and the solutions I’ve found for those (or about some specific things about the Cinnamon desktop/the French keyboard).
So I hope you won’t be upset if I feel the need to correct a few things you wrote in your post…
And please do the same if you find I’m wrong 
I will use the same format as you did, because I find it very clear, much more readable like this and I already know that will be a long post…
Which files removed manjaro-hotfixes exactly?
Two files were deleted with the help of a dummy package:
$ pamac list -f manjaro-hotfixes
/etc/dbus-1/system.d/org.freedesktop.NetworkManager.Manjaro.conf
/etc/polkit-1/rules.d/99-manjaro.rules
So let’s get the first one out of the way
$ cat /etc/dbus-1/system.d/org.freedesktop.NetworkManager.Manjaro.conf
<!DOCTYPE busconfig PUBLIC
"-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
<policy group="network">
<deny own="org.freedesktop.NetworkManager"/>
<allow send_destination="org.freedesktop.NetworkManager"/>
<allow send_destination="org.freedesktop.NetworkManager"
send_interface="org.freedesktop.NetworkManager.Settings"/>
<allow send_destination="org.freedesktop.NetworkManager"
send_interface="org.freedesktop.NetworkManager.AgentManager"/>
<deny send_destination="org.freedesktop.NetworkManager"
send_interface="org.freedesktop.NetworkManager"
send_member="SetLogging"/>
<allow send_destination="org.freedesktop.NetworkManager"
send_interface="org.freedesktop.NetworkManager"
send_member="Sleep"/>
<allow send_destination="org.freedesktop.NetworkManager"
send_interface="org.freedesktop.NetworkManager"
send_member="sleep"/>
<allow send_destination="org.freedesktop.NetworkManager"
send_interface="org.freedesktop.NetworkManager"
send_member="wake"/>
</policy>
</busconfig>
That’s some configuration for NetworkManager and the network group (<policy group="network">), and it really seems unneeded now indeed, because I didn’t see any changes after removing it, and I’m sure there would be already some reports if it did break some users networks
Now, let’s have a look to 99-manjaro.rules
Here is the whole thing:
$ sudo cat /etc/polkit-1/rules.d/99-manjaro.rules
polkit.addRule(function(action, subject) {
if (action.id.indexOf("org.freedesktop.udisks2.") == 0 && subject.isInGroup("wheel")) {
return polkit.Result.YES;
}
});
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.login1.power-off" ||
action.id == "org.freedesktop.login1.reboot" ||
action.id == "org.freedesktop.login1.hibernate" ||
action.id == "org.freedesktop.login1.suspend") {
return polkit.Result.YES;
}
});
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.upower.hibernate" ||
action.id == "org.freedesktop.upower.suspend") {
return polkit.Result.YES;
}
});
/* Allow users of network group to use blueman feature requiring root without authentication */
polkit.addRule(function(action, subject) {
if ((action.id == "org.blueman.network.setup" ||
action.id == "org.blueman.dhcp.client" ||
action.id == "org.blueman.rfkill.setstate" ||
action.id == "org.blueman.pppd.pppconnect") &&
subject.isInGroup("network")) {
return polkit.Result.YES;
}
});
So that’s 4 times adding Polkit rules (polkit.addRule) to use features requiring root without authentication, that means changing the standard "auth_admin" to "yes".
Ref: polkit: polkit Reference Manual
Let’s break it in smaller pieces, starting with the last part:
Blueman
The wheel group was used before, but it was changed to the network group (as can be see in the file) by this commit:
So now this part is also gone because it seems unneeded now, but I can’t say if it makes any problem, as I don’t use any Bluetooth device… Same thing, if it does, users report will come soon enough!
In the middle of the file:
login1 & upower
Some rules added to allow an user to hibernate, suspend, reboot and power-off without authentication.
Not needed anymore today, so also gone and tested without problems on my side (outside of hibernate, that I don’t use)…
At last, on the top of the file:
polkit rule for passwordless mount with udisks2
Again, that’s just changing the standard "auth_admin" to "yes", to allow a passwordless mount of devices with udisks2.
That trick was even black and white in the Arch Wiki once (https://archive.ph/f7aod), but it is now also removed from the actual version (udisks - ArchWiki) and instead, there’s some external examples, like this one here _Example polkit rules_.md · GitHub (with the same polkit rule, by the way) or that one Permissions · coldfix/udiskie Wiki · GitHub for the storage group.
And I think that’s why you talking about this storage group here…
In fact, my user is not even in this group, and with this polkit rule, I can nevertheless mount any devices without password, because I’m in the wheel group.
But if anybody doesn’t want to add it’s user(s) to the wheel group because it’s a security risk, this polkit rule also works by using instead the group named after the user…
I did the test, it works, but I never bothered before, as I always added my user to the wheel group on Linux if it wasn’t done by default after the install, because that’s what I’m used to do on BSD and I’m the sole user of my PC at home…
Historically after all, the wheel group is the default UNIX admin group, but yes, less permissions is more safety and not everybody seems to like it The wheel Group – UNIX Administratosphere
So, to each his own…
The addition of a polkit rule for passwordless mount seems to have be seen as a “hack” since a long time, as can be read here: udisks2 + polkit 0.107: Allow unauthenticated mounting / Applications & Desktop Environments / Arch Linux Forums
Quote: “It should be noted that these rules are indeed not necessary if you are using systemd/logind. These rules are and always have been a hack/workaround to make things work without a proper consolekit/logind session. The fact is that 99% of users don’t have to create polkit rules ever, so imho people shouldn’t be encouraged to do so.”
Yeah… And yet, here we are, 12 years later and if I remove this rule, I’m still asked for a password when I want to mount my internal drives, so that’s a nope for me!
Which means, unless I missed a configuration step with systemd or whatever else, we are still in the same situation, it seems…
So I hope this helps clarify a bit more the situation for anybody who still has questions about this manjaro-hotfixes update/removal thing!
TL;DR:
- manjaro-hotfixes update removed 2 files. One was really unneeded
(/etc/dbus-1/system.d/org.freedesktop.NetworkManager.Manjaro.conf), most of the second was too (/etc/polkit-1/rules.d/99-manjaro.rules)… - but the useful part that has been removed in the latter allowed passwordless mount that was added in a polkit rule.
- to get that behavior back, look at this post [Stable Update] 2024-01-13 - Kernels, Systemd, Qt5, Mesa, Dbus, Firefox, Thunderbird - #123 by fsw
- use the group you want in the file:
wheel, if you’re already in it, add yourself instorageif you want, or use the group that has yourusername, that will work too (and implies way less permissions, so is more safe that the 2 other options). - no need for the
wheelgroup with blueman, because it was changed tonetworkgroup a while ago anyway and now no special configuration seems to be needed anymore (can’t confirm, don’t use Bluetooth).
2 Likes
Hmm - it is strange that removing those rules - is creating such issue.
I now realize that the complete file is posted - that I have looked some change which involved the storage group which I know is obsolete - so my reference to that is clearly wrong - my sincere apology.
When I look at Users and groups - ArchWiki specifically the list of group - it seems there is quite a lot of groups which are no longer necessary.
When you say that removing the rules creates issues for your system - as in passwd required to mount an internal, attached device - I can safe say there is something unhinged going on with your system.
My fstab is as short as they come everything else is mounted using systemd mount units - and fstab is - when parsed on load time - converted to native unit files.
I mount several devices at boot - none of these requires my user to be member of the storage group.
The group list - referred above - tells me the storage group is a [pre-systemd groups] which no longer is required as udev handles the access.
Listing my current group list makes me realize that a cleanup is needed
$ groups
sys network power nordvpn lp wheel fh
- network and power appear to be unused
- lp is for accessing hardware printing ports
- sys is used for handling printers using CUPS
So for my usecase I can remove network power lp wheel from my group list
$ groups
sys nordvpn fh
I can only guess why such a decision was made years ago - neither can I guess the reasoning behind but life with Arch is an ongoing travel which you have to adjust yourself to.
At the time I get from the package history, at time I my involvement was learning Python and coding pacman-mirrors in the process.
Starting today, I get this:
When trying to open an external HDD. Internal ones work fine after password prompt, this one just gives this. I did nothing. Do I have to open another topic for this?
EDIT:
Apparently not related. Did a check and fix on the disk from Windows and it got solved. 
Different issue …
See other posts regarding the ntfs3 module as opposed to ntfs-3g …
Basically it doesnt force-mount … so you see things like that in cases you normally otherwise would not have with the old ntfs-3g module.
Which is a good thing - take care to make sure to fully shut down windoze for example.
Hi, and thanks for your reply.
No need to apologize, everybody can get things mixed up, and me the first
But I really appreciate the gesture anyway, it’s seems to get harder and harder to find somebody able to do so, whereas to me it’s one of the greatest strength somebody can have…
Thanks also for pushing me to refresh my knowledge about the groups, that’s a very crucial part of any UNIX and UNIX-like system, after all!
So, in my case, I have:
$ groups
sys network power gamemode autologin lp wheel
Plus the one named after my user.
So yeah, I could use a bit of cleanup too!
As you said, sys is used for handling printers using CUPS, but so are the groups wheel and root.
See in CUPS - ArchWiki chapter 6.1.1:
User groups with printer administration privileges are defined in SystemGroup in the /etc/cups/cups-files.conf . The sys and root and wheel groups are used by default.
$ sudo cat /etc/cups/cups-files.conf
(...)
# Administrator user group, used to match @SYSTEM in cupsd.conf policy rules...
# This cannot contain the Group value for security reasons...
SystemGroup sys root wheel
So, if the user is in the wheel group or if the printer is configured once by root, he doesn’t even need to be in the sys group anymore, as I understand it correctly…
I don’t have any printer, so I will try to remove my user from the sys group and see if there’s any side effect. Surely a good thing for security, as it was abused in the past, it seems:
https://bbs.archlinux.org/viewtopic.php?id=148960
Funny thing: again, writing a custom Polkit rule allows members of the wheel group to administer printers without a password, see chapter 6.1.2 from the link above…
The network group seems only to be used today to be able to add and remove networks without a password in SSH sessions. The user must be in this group, as in the wheel group (again) and also with the need of a custom Polkit rule:
https://wiki.archlinux.org/title/NetworkManager#Set_up_PolicyKit_permissions
So no need for being in it, if not in this case.
The power group was needed in the good old days before HAL and systemd, so it’s really obsolete now:
https://www.linuxquestions.org/questions/slackware-14/shutdown-without-su-757413/
https://bbs.archlinux.org/viewtopic.php?id=98408
Specific to my system, gamemode is a nice trick to get the most of the ressources when playing games, and autologin is specific to LightDM, which comes with my Cinnamon desktop.
But I’m only using autologin on another machine, and not my main PC, so I can also remove my user from it…
And finally, I’m not using anything on my parallel port, so that’s not needed either!
So, grand total is now:
$ groups
gamemode wheel
Plus the one named after my user. That’s an early springs cleaning!
As I noticed in my first message above, and thank to this thread, the custom rule for passwordless mounting an internal drive ondemand with a file manager is also working with the group named after my user, so I could even delete it from the wheel group, it seems…
And that bring us to the second topic of your reply:
Again, with all due respect, I don’t think so…
See, I remember having to do that trick a long time ago, even before using Manjaro, but with files ending with the .pkla extension in Debian and derivatives, like in this example:
https://askubuntu.com/questions/552503/stop-asking-for-authentication-to-mount-usb-stick/1424539#1424539
And each time this question is asked for the same exact situation I want to achieve, the same exact “hack” comes over and over again as an answer:
https://bbs.archlinux.org/viewtopic.php?id=272738
That was only after a quick search, but I’m sure I could find much more, older ones, and for other distros too…
The only thing I got in my fstab is my root partition, and my swap. I don’t want anything else mounted automatically at startup, because of security reasons.
I just want to access my drives when I want to, and that from my file manager, by clicking on it, but without having to put a password, and there is no other way to do that I’ve found, so far…
Even Arch wiki is admitting it:
polkit - ArchWiki chapter 3.3.3, quote:
File managers may ask for a password when trying to mount a storage device, or yield a Not authorized or similar error. See Udisks#Configuration for details.
Wich brings to the same solution of a modified Polikt rule, as noted in my first post.
But it’s nothing personal with Arch or Manjaro, actually for my work, I have to have installed (along Windows 10/11 and macOS) all of the “big” Linux distros (Debian, Ubuntu, OpenSuse, Mageia, Fedora, Red Hat clone, and a few others more), so I had to actually put this Polkit rule (in one format or another) on each one of those!
I’m curious if that will be the same thing on FreeBSD, I have just reinstalled it for fun after a long pause (I still have an old laptop with 8.3 on it that I didn’t booted for years, now we are at 14!), we shall see…
So, seing the numerous posts using this “hack” on the Web to solve this issue, plus the fact that almost 10 people already thanked me for posting it on the last stable update thread, I really don’t think the problem lies in my system…
TL;DR of this very long post again (sorry), if somebody is interested:
- a lot of the groups to which an user is added are actually obsolete, or only needed in very specific use cases. After inspection, the user could be removed from a lot of those, for a better security.
- WARNING: do it at your own risk, and don’t come back to me if you break something! Knowledge is power, and the Arch wiki quoted above is a good source to understand the role of the various groups.
- as for now, I don’t see any other way for a passwordless mount of internal drive ondemand FROM a file manager (and NOT automatically at startup from
/etc/fstab), without a modified Polkit rule. Even the Arch wiki seems to acknowledge that, but if somebody do, I’m all ears… - that’s nothing specific to Manjaro or even Arch, I actually have to do that to every single Linux distro I’m using, whatever the flavour is! Actually, I already needed to do that a long time ago, and on Debian and derivated distros, the file to edit has a .pkla extension…
- modifiying/writing a custom Polkit rule to do things without a password seems more common that I first thought, see links above for configuring CUPS or using NetwokManager in a SSH session…
And that’s exactly when you need your user in thewheelgroup (for the both case), and also in thenetworkgroup (only for the 2nd case).