New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nautilus fails when accessing a virtual block devices #390

Closed
marmarek opened this Issue Mar 8, 2015 · 14 comments

Comments

Projects
None yet
2 participants
@marmarek
Member

marmarek commented Mar 8, 2015

Reported by joanna on 21 Dec 2011 09:42 UTC
When one connects a block device using qvm-block to some AppVM, then the device's volumes are properly displayed by Nautilus running in the VM, however, when one clicks on the volume(s), Nautilus fails with some auth failure.

Migrated-From: https://wiki.qubes-os.org/ticket/390

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by joanna on 21 Dec 2011 09:43 UTC
The fail message is actually: Unable to mount volume.

Member

marmarek commented Mar 8, 2015

Comment by joanna on 21 Dec 2011 09:43 UTC
The fail message is actually: Unable to mount volume.

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by marmarek on 27 Dec 2011 12:45 UTC
gvfsd is started by dbus (session bus), which doesn't have ConsoleKit session cookie yet.
Solution: start CK session earlier.

Member

marmarek commented Mar 8, 2015

Comment by marmarek on 27 Dec 2011 12:45 UTC
gvfsd is started by dbus (session bus), which doesn't have ConsoleKit session cookie yet.
Solution: start CK session earlier.

@marmarek marmarek assigned marmarek and unassigned rootkovska Mar 8, 2015

@marmarek

This comment has been minimized.

Show comment
Hide comment

@marmarek marmarek closed this Mar 8, 2015

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by joanna on 29 Dec 2011 14:54 UTC
I'm still getting auth failure from nautilus. Manual mount (as sudo root) works ok.

Member

marmarek commented Mar 8, 2015

Comment by joanna on 29 Dec 2011 14:54 UTC
I'm still getting auth failure from nautilus. Manual mount (as sudo root) works ok.

@marmarek marmarek reopened this Mar 8, 2015

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by joanna on 29 Dec 2011 15:03 UTC
Hmmm.... Interestingly, after I rebooted the dest VM (to which I was connecting the block device), now it worked fine -- I got a volume in nautilus and was able to click on it and it was mounted ok.

Do we have some race there?

Member

marmarek commented Mar 8, 2015

Comment by joanna on 29 Dec 2011 15:03 UTC
Hmmm.... Interestingly, after I rebooted the dest VM (to which I was connecting the block device), now it worked fine -- I got a volume in nautilus and was able to click on it and it was mounted ok.

Do we have some race there?

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by marmarek on 29 Dec 2011 15:07 UTC
Did you restarted dest VM after GUI package upgrade? There should be no place for race now (in previous version it was possible, but still - not with gvfsd).

Member

marmarek commented Mar 8, 2015

Comment by marmarek on 29 Dec 2011 15:07 UTC
Did you restarted dest VM after GUI package upgrade? There should be no place for race now (in previous version it was possible, but still - not with gvfsd).

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Modified by joanna on 29 Dec 2011 21:46 UTC

Member

marmarek commented Mar 8, 2015

Modified by joanna on 29 Dec 2011 21:46 UTC

@marmarek marmarek added the worksforme label Mar 8, 2015

@marmarek marmarek closed this Mar 8, 2015

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by joanna on 1 Jan 2012 14:21 UTC
Just run into this problem again:

Jan  1 15:17:04 localhost ck-xinit-session-qubes: error connecting to console-kit (org.freedesktop.CkConnector.Error: Unable to open session: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.)
Jan  1 15:17:04 localhost kernel: [   34.509258] u2mfn_mmap: entering, private=          (null)
Jan  1 15:17:04 localhost kernel: [   34.509282] u2mfn_mmap: calling remap return 0
Jan  1 15:17:04 localhost kernel: [   34.509302] u2mfn_release, priv=          (null)
Jan  1 15:17:04 localhost gnome-keyring-daemon[couldn't set environment variable in session: The name org.gnome.SessionManager was not provided by any .service files
Jan  1 15:17:04 localhost gnome-keyring-daemon[1009](1009]:): couldn't set environment variable in session: The name org.gnome.SessionManager was not provided by any .service files
Jan  1 15:17:04 localhost gnome-keyring-daemon[couldn't set environment variable in session: The name org.gnome.SessionManager was not provided by any .service files
Jan  1 15:17:05 localhost kernel: [   35.340787](1009]:) fuse init (API version 7.16)
Jan  1 15:17:05 localhost dbus-daemon: [Rejected send message, 2 matched rules; type="method_call", sender=":1.19" (uid=500 pid=1137 comm="nautilus) interface="org.freedesktop.DBus.Properties" member="GetAll" error name="(unset)" requested_reply=0 destination=":1.3" (uid=0 pid=762 comm="/usr/sbin/console-kit-daemon))
Jan  1 15:17:44 localhost kernel: [   74.824348](system]) blkfront: xvdi: barrier or flush: disabled
Jan  1 15:17:44 localhost kernel: [   74.827884]  xvdi: xvdi1
Member

marmarek commented Mar 8, 2015

Comment by joanna on 1 Jan 2012 14:21 UTC
Just run into this problem again:

Jan  1 15:17:04 localhost ck-xinit-session-qubes: error connecting to console-kit (org.freedesktop.CkConnector.Error: Unable to open session: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.)
Jan  1 15:17:04 localhost kernel: [   34.509258] u2mfn_mmap: entering, private=          (null)
Jan  1 15:17:04 localhost kernel: [   34.509282] u2mfn_mmap: calling remap return 0
Jan  1 15:17:04 localhost kernel: [   34.509302] u2mfn_release, priv=          (null)
Jan  1 15:17:04 localhost gnome-keyring-daemon[couldn't set environment variable in session: The name org.gnome.SessionManager was not provided by any .service files
Jan  1 15:17:04 localhost gnome-keyring-daemon[1009](1009]:): couldn't set environment variable in session: The name org.gnome.SessionManager was not provided by any .service files
Jan  1 15:17:04 localhost gnome-keyring-daemon[couldn't set environment variable in session: The name org.gnome.SessionManager was not provided by any .service files
Jan  1 15:17:05 localhost kernel: [   35.340787](1009]:) fuse init (API version 7.16)
Jan  1 15:17:05 localhost dbus-daemon: [Rejected send message, 2 matched rules; type="method_call", sender=":1.19" (uid=500 pid=1137 comm="nautilus) interface="org.freedesktop.DBus.Properties" member="GetAll" error name="(unset)" requested_reply=0 destination=":1.3" (uid=0 pid=762 comm="/usr/sbin/console-kit-daemon))
Jan  1 15:17:44 localhost kernel: [   74.824348](system]) blkfront: xvdi: barrier or flush: disabled
Jan  1 15:17:44 localhost kernel: [   74.827884]  xvdi: xvdi1

@marmarek marmarek removed the worksforme label Mar 8, 2015

@marmarek marmarek reopened this Mar 8, 2015

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by joanna on 1 Jan 2012 14:23 UTC
Must be a race, because after I restarted the AppVM and reattached the block device, it worked fine now.

Member

marmarek commented Mar 8, 2015

Comment by joanna on 1 Jan 2012 14:23 UTC
Must be a race, because after I restarted the AppVM and reattached the block device, it worked fine now.

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by marmarek on 1 Jan 2012 16:34 UTC
The above ck-xinit-session-qubes error is normal, look here: http://git.qubes-os.org/gitweb/?p=marmarek/gui.git;a=commit;h=e8873f734cf4463684d559cfdecb3cb1ac0245d3

But the second one (dbus reject) looks suspicious.

Member

marmarek commented Mar 8, 2015

Comment by marmarek on 1 Jan 2012 16:34 UTC
The above ck-xinit-session-qubes error is normal, look here: http://git.qubes-os.org/gitweb/?p=marmarek/gui.git;a=commit;h=e8873f734cf4463684d559cfdecb3cb1ac0245d3

But the second one (dbus reject) looks suspicious.

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by marmarek on 2 Jan 2012 15:43 UTC
Ok, the first message doesn't come from "dummy" creating session. Moreover - this happens not only for the first started session in VM...

Member

marmarek commented Mar 8, 2015

Comment by marmarek on 2 Jan 2012 15:43 UTC
Ok, the first message doesn't come from "dummy" creating session. Moreover - this happens not only for the first started session in VM...

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Modified by marmarek on 13 Jan 2012 12:38 UTC

Member

marmarek commented Mar 8, 2015

Modified by marmarek on 13 Jan 2012 12:38 UTC

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Modified by marmarek on 15 Jan 2012 04:05 UTC

Member

marmarek commented Mar 8, 2015

Modified by marmarek on 15 Jan 2012 04:05 UTC

@marmarek marmarek closed this Mar 8, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment