[SOLVED] Mount permissions all over the place

[jaywalker]

I cannot tell if this is a bug or if it is a side-effect of updating beta1 to beta2, or if it some other mysterious occurrence. My up-to-date Beta 1 installation has started to seek root permissions for mounting external drive linux and ntfs-3g partitions. It only ever did this before for vfat.

Can anyone tell me where are the rules which govern the mount process because I can't find them.

In contrast, my fresh install of Beta2 behaves properly.

Richard

[doktor5000]

For external ntfs-3g partitions? Have those been safely removed/unmounted before?

For more information on this, see the following thread: viewtopic.php?f=8&t=710
or for the interesting part start from Ahmad's post: viewtopic.php?p=5136#p5136

[jaywalker]

Let me check. The drive was formatted for use with a DVB set top box. Either I did it, or I let the STB do it - can't remember now....

[jaywalker]

Yep, here's what diskdrake says about it:

Code: Select all

Device: sdh1
Volume label: RECORDINGS
UUID: 1D6B6CE21D6B6D29
DOS drive letter: C (just a guess)
Type: NTFS-3G (0x7)


I have been using it with MGA1 since October and with Cauldron since mid-Feb - No problems mounting/unmounting before now, and only with the up-to-date Beta1. The fresh Beta2 still handles it OK.

Richard

PS. Having skimmed through the referenced posts it might be worth saying I use LXDE and udisks2, not forgetting HAL and anyone else who wants to get involved I cannot check now but I imagine MGA1 is using udisks1 and HAL and whatever for handling external drive stuff.

[doktor5000]

Well, the behaviour you described should only happen for internal partitions, and for external ntfs-3g partitions only in case the filesystem is marked in need for a filesystem check. You should try to mount it via a terminal, as ntfs-3g will tell you what the problem is. If there is none, then you need to follow the hints in above linked thread, and create such an authentication file. If there is a problem, please post it here.

Maybe check http://www.tuxera.com/community/ntfs-3g-manual/#8 for how to do the mounting.

[jaywalker]

I think we are overlooking the fact that whatever the problem is, it is causing a permissions request for both linux and ntfs external partitions where last week it did not. As use with ntfs has otherwise been problem-free I think I should try to find where my system decides who should and who shouldn't mount (and unmount in the case of vfat and some USB sticks (possibly vfat also) . I just want to make it the same as my other Beta2 installation.

Richard

Must dash - coffee break over. The sun is still shining and I have to get my front brakes back on the car

[doktor5000]

Can you post a screenshot of the error message you get? Also f.ex. in dolphin you'll get an additional error message at the bottom of the window, where it will be shown in some light red, additional to the popup dialog asking for the rooot password. That one would also be useful.

[jaywalker]

OK, here goes. One for external EXT4 and one for external NTFS

AuthenticateEXT4.png (28.34 KiB) Viewed 6580 times

AuthenticateNTFS.png (27.94 KiB) Viewed 6580 times

[jaywalker]

Also, on authenticating I get this in /var/log/messages

Code: Select all

Mar 18 17:07:22 Tureen udisksd[2367]: Mounted /dev/sdc20 at /run/media/rich/FILMS on behalf of uid 501
Mar 18 17:07:22 Tureen halevt: Running: /usr/bin/halevt-explore-mount "/run/media/rich/FILMS"
Mar 18 17:07:22 Tureen halevt: Running: halevt-mount -s


and for the NTFS partition:

Code: Select all

Mar 18 17:09:20 Tureen ntfs-3g[10344]: Version 2012.1.15 external FUSE 28
Mar 18 17:09:20 Tureen ntfs-3g[10344]: Mounted /dev/sdh1 (Read-Write, label "RECORDINGS", NTFS 3.1)
Mar 18 17:09:20 Tureen ntfs-3g[10344]: Cmdline options: rw,nosuid,nodev,uhelper=udisks2,uid=501,gid=501,dmask=0077,fmask=0177
Mar 18 17:09:20 Tureen ntfs-3g[10344]: Mount options: rw,nosuid,nodev,uhelper=udisks2,allow_other,nonempty,relatime,fsname=/dev/sdh1,blkdev,blksize=4096,default_permissions
Mar 18 17:09:20 Tureen ntfs-3g[10344]: Global ownership and permissions enforced, configuration type 1
Mar 18 17:09:20 Tureen udisksd[2367]: Mounted /dev/sdh1 at /run/media/rich/RECORDINGS on behalf of uid 501
Mar 18 17:09:20 Tureen halevt: Running: /usr/bin/halevt-explore-mount "/run/media/rich/RECORDINGS"
Mar 18 17:09:20 Tureen halevt: Running: halevt-mount -s


UPDATE
I have just checked log messages for the two cases as above on the freshly installed and up-to-date Beta2 system (where no root authentication is needed). There is no material difference in the information logged. If there is a difference it looks more likely to be something related to LXDE/pcmanfm, or in the configuration of external drive access authority, wherever that may be.

[doktor5000]

Yes, that's what i was thinking of. See the above linked thread, create the file mentioned there, and you should not see this again.
Although i can't tell you why you get this only for some partitions, and only on this machine. Could also be that these instructions given there
need to be updated for udisks2, but i can't really tell as i've currently no time to check back with cauldron.

[jaywalker]

Thanks Dok, I found what might be the answer to my original question in the comments to a post referenced in the thread you pointed me to. Cutting out the middle-men it is the last (so far) comment from Silver Knight at http://mdzlog.alcor.net/2010/06/27/navi ... ykit-maze/

If my understanding is accurate then I should find locally administered policies in /etc/polkit-1/localauthority and policies provided by packages in /var/lib/polkit-1/localauthority. This information is also in the man page for pklocalauthority. So I'm off to check now in my faulty Beta2. I expect to find /etc/polkit-1/localauthority essentially empty as I have not yet created any local policies. I expect that /var/lib/polkit-1/localauthority might have some policies installed by packages I have installed. If both are "empty" then I expect that it is the default policies which are in force. All I have to do is find them.

regards

Richard

[doktor5000]

Well, that information is a bit outdated, check the second link i gave, viewtopic.php?p=5136#p5136
for the nessary information. That's what i'm using on Mageia 1 to access internal partitions, otherwise i'd get a similar error/password request as posted above.

[jaywalker]

It was Ahmad's post which pointed me to the Silver Knight's comment on the correct location for the local admin policies. I can now confirm that there is no difference between the 2 Beta2s - they both lack alteration of the default policies which I have now found: /usr/share/polkit-1/actions

Specifically it appears to be org.freedesktop.udisks2.policy in control as that is the reference you can see in the screenshot of the Authenticate pop-up.

But as this is the same in both installations it is likely a red-herring. At the moment I am inclined to pursue this problem:

Code: Select all

[rich@Tureen ~]$ ck-list-sessions
Session9:
   unix-user = '501'
   realname = 'Rich'
   seat = 'Seat10'
   session-type = ''
   active = FALSE
   x11-display = ':0.0'
   x11-display-device = '/dev/tty2'
   display-device = ''
   remote-host-name = ''
   is-local = FALSE
   on-since = '2012-03-18T22:15:12.656072Z'
   login-session-id = '4294967295'


In particular note that I am regarded as being neither active nor local. Following the rules in org.freedesktop.udisks2.policy I must therefore be prompted for root authentication as an "any" user.

Does this ring a bell with anyone? It is also stopping me from shutting down from the desktop. There is a HAL power management policy preventing it, presumably for the same reason.

Oh, and there is the weird way this Beta2 starts the desktop login:

Code: Select all

x11-display-device = '/dev/tty2'

Richard

[jaywalker]

Perhaps console-kit is a red herring too. It looks like it is just reacting to a problem caused earlier during start-up. Possibly this is the same error which causes the plymouth-wait-quit,service to fail (file not found; now there's cryptic for you)

Code: Select all

[root@Tureen rich]# systemctl status plymouth-wait-quit.service
plymouth-wait-quit.service
     Loaded: error (Reason: No such file or directory)
     Active: inactive (dead)



The fail message is the last entry on tty1, which I suppose is why the LXDE login screen appears on tty2., and probably why console-kit thinks I am an inactive and remote user.

[doktor5000]

Nope, it's totally unrelated, from what i can see you only get that last posted error because that service is named otherwise (because there's no such error as "this service doesn't exist / not found"). Actually i'm tired of reposting that link from above for a third time, feel free to chase more red herrings :/

[jaywalker]

I am so sorry Dok. I was focussing on what Ahmad said about creating a special local user policy for udisks-1 and relating that to how it might work with udisks2. I completely overlooked the second page of your troubleshooting analysis with dexter11.

It's late now. I have had to rebuild the working Beta2 install (and yes, trouble-free mounting through the file manager still works there) so I will get back to this flaky Beta1->Beta2 updated system tomorrow after I have studied the rest of that thread.

Richard

[jaywalker]

Well now, that took almost a week (since the Beta2 update of the working Beta1 system) but now I feel almost euphoric. Once more can I click on an external drive icon in the file manager to mount it without entering a root password, and even better, I understand 80% of what went wrong.

It started the day before Beta2 was released. I was exploring display manager alternatives to the rather ugly, but perfectly functional LXDM. I installed SLiM but didn't use it straight away as I was experimenting with configuration changes to LXDM. Nothing seemed to make much of a difference until I re-booted and saw what I thought was an alternative version of LXDM which was less ugly, but decidedly minimalist. What I didn't know until tonight is that it was actually SLiM which was now in use.

I don't know how it caused the malfunction, but while I was inadvertently using the SLiM dm to log in to LXDE the vt1 console was always busy when the dm started (and stayed busy) so the log-in was always on vt2. As well as that, Console-Kit was convinced that I was not either an "active" or a "local" user. I could see this from the output of

Code: Select all

[rich@Tureen ~]$ ck-list-sessions
Session9:
   unix-user = '501'
   realname = 'Rich'
   seat = 'Seat10'
   session-type = ''
   active = FALSE
   x11-display = ':0.0'
   x11-display-device = '/dev/tty2'
   display-device = ''
   remote-host-name = ''
   is-local = FALSE
   on-since = '2012-03-22T01:07:11.139010Z'
   login-session-id = '4294967295'


The knock-on effect was that udisks2 default rules in /usr/share/polkit-1/actions/org.freedesktop.udisks2.policy

Code: Select all

  <action id="org.freedesktop.udisks2.filesystem-mount">
    <description>Mount a filesystem</description>
    <message>Authentication is required to mount the filesystem</message>
    <defaults>
      <allow_any>auth_admin</allow_any>
      <allow_inactive>auth_admin</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
  </action>


would only permit a password-free mount of external drives for an "active" user and as it asks consolekit for the user's status it was failing.

When I switched back to LXDM from SLiM the boot process on vt1 now completed correctly, the log-in screen is displayed there and I am both "active" and "local" in my LXDE session,

Code: Select all

[rich@Tureen ~]$ ck-list-sessions
Session1:
   unix-user = '501'
   realname = 'Rich'
   seat = 'Seat1'
   session-type = ''
   active = TRUE
   x11-display = ':0'
   x11-display-device = '/dev/tty1'
   display-device = ''
   remote-host-name = ''
   is-local = TRUE
   on-since = '2012-03-22T00:57:52.033790Z'
   login-session-id = '1'


according to consolekit. And guess what, mounting external drives works again.

I'm calling that a result. And possibly a bug in SLiM too, as it does not play so well with consolekit.

UPDATE; https://bugs.mageia.org/show_bug.cgi?id=5051