Hmm, on my SX:CE build 124 box (full install, no upgrade)
mount, unmount and eject works just fine for a non root user...

(In reply to comment #1)
> Hmm, on my SX:CE build 124 box (full install, no upgrade)
> mount, unmount and eject works just fine for a non root user...

Ok, try it again on OpenSolaris.  I've noticed that the two act differently
sometimes.

thanks,
alan

On the same notebook running opensolaris 2010.20 b125 the problem 
is reproducible.

(In reply to comment #3)
> On the same notebook running opensolaris 2010.20 b125 the problem 
> is reproducible.

Thank you. :-)

alan

Also broken for me:

grinah$ eject
eject of cdrom /dev/dsk/c4t0d0s2 failed: Rejected send message, 2 matched
rules; type="method_call", sender=":1.27" (uid=37845 pid=2893 comm="")
interface="org.freedesktop.Hal.Device.Storage" member="Eject" error
name="(unset)" requested_reply=0 destination="org.freedesktop.Hal" (uid=0
pid=540 comm=""))

grinah$ eject 1GBFLASH
unmount of 1GBFLASH /dev/dsk/c5t0d0p0 failed: Rejected send message, 2 matched
rules; type="method_call", sender=":1.28" (uid=37845 pid=2899 comm="")
interface="org.freedesktop.Hal.Device.Volume" member="Unmount" error
name="(unset)" requested_reply=0 destination="org.freedesktop.Hal" (uid=0
pid=540 comm=""))

I finally figured out a better workaround.

Use rmformat to get the /dev....

Then fdisk /dev....

Delete all partitions, and create one Solaris2 partition.

Then zpool create pool_name /dev....

Then start writing to it. :-)

Then zpool export pool_name.

Works wonderfully well. <vbg>

(In reply to comment #6)
> I finally figured out a better workaround.

Did we already had a workaround?


> Use rmformat to get the /dev....
> 
> Then fdisk /dev....
> 
> Delete all partitions, and create one Solaris2 partition.
> 
> Then zpool create pool_name /dev....
> 
> Then start writing to it. :-)
> 
> Then zpool export pool_name.
> 
> Works wonderfully well. <vbg>


Hmm - and that helps with ejecting optical media?

(In reply to comment #0)
> This started with 124 and continues on build 125.
> 
> If you insert optical or usb media and then try to right click on them and
> select either eject or unmount it no longer works.
> 
> The workaround is to either su to root or use pfexec to eject the media.
> 
> pfexec eject for optical

Seems that ownership of the /dev/console device has changed between 
opensolaris b123 and b125 when a regular user is logged in.

In b123 the /dev/console file was owned by the non-root user.
In b125 root owns /dev/console.

After changing the owner of /dev/console to the non-root user
that is running the gui session, eject command starts to work.

Bug 6885612... 

    "Console user" profile implementation need to be updated after Virtual
Console integration
    http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6885612

... contains a hint that due to the virtual consoles feature the login
user now owns /dev/vt/2 instead of /dev/console.

(In reply to comment #9)
> Bug 6885612... 
> 
>     "Console user" profile implementation need to be updated after Virtual
> Console integration
>     http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6885612
> 
> ... contains a hint that due to the virtual consoles feature the login
> user now owns /dev/vt/2 instead of /dev/console.

Absolutely not.  I'll try what you posted because I still need to have at least
one FAT32 USB device.  But!!! zfs on a usb key is really cool.  The downside is
that it isn't automatically mounted or unmounted.  zpool import, zpool export. 
I would imagine that compression would work as well.

thanks for the console tip,
alan

(In reply to comment #8)
> (In reply to comment #0)
> > This started with 124 and continues on build 125.
> > 
> > If you insert optical or usb media and then try to right click on them and
> > select either eject or unmount it no longer works.
> > 
> > The workaround is to either su to root or use pfexec to eject the media.
> > 
> > pfexec eject for optical
> 
> Seems that ownership of the /dev/console device has changed between 
> opensolaris b123 and b125 when a regular user is logged in.
> 
> In b123 the /dev/console file was owned by the non-root user.
> In b125 root owns /dev/console.
> 
> After changing the owner of /dev/console to the non-root user
> that is running the gui session, eject command starts to work.

Ok, so a chown from root to user and I can once again eject FAT32 usb drives
and optical media.  

I'll assume that the other bug report will be the permanent fix so is it ok to
close this one?  If not, is chmod better than chown?

thanks,
alan

(In reply to comment #11)

> Ok, so a chown from root to user and I can once again eject FAT32 usb drives
> and optical media.  
> 
> I'll assume that the other bug report will be the permanent fix so is it ok to
> close this one? 

I'm not sure if 6885612 will fix the same issue.

But it does explain what has changed in b124.



> If not, is chmod better than chown?

I think chown is needed.

This also breaks VirtualBox, which can no longer access the DVD drive.

(In reply to comment #12)
> (In reply to comment #11)
> 
> > I'll assume that the other bug report will be the permanent fix so is it ok to
> > close this one? 
> 
> I'm not sure if 6885612 will fix the same issue.

But it contains links to quite a few bugs that show breakage in other 
areas (xterm -C, nwam, printer queues, ...) that are caused by /dev/console
being owned by root.

Looking at one of the bugs, 6886849
"login user does not own /dev/console when login in gdm 2.20.x"
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6886849
seems to contain a hint that something was changed in b126 gnome
session to work around the /dev/console owner problems...

(In reply to comment #13)
> This also breaks VirtualBox, which can no longer access the DVD drive.

I don't think so, because on my b124 SX:CE box it do own the 
/dev/console device when I login as a regular user, but
VirtualBox 3.0.8 isn't able to access the dvd drive hardware.

Which version of VirtualBox are you running ?


I think this is a bug in the OpenSolaris VirtualBox 3.0.8
release:

    http://forums.virtualbox.org/viewtopic.php?f=11&t=23392

> Which version of VirtualBox are you running ?

3.0.8

> I think this is a bug in the OpenSolaris VirtualBox 3.0.8
> release:
> 
>     http://forums.virtualbox.org/viewtopic.php?f=11&t=23392

I think you are probably right, although the symptoms are very similar - thanks
for the reference Jürgen :-)

Jürgen, I think the root cause of this *is* 6885612 especially after some
discussions earlier with Gary Winiger.

In any case, marking this as a potential blocker for the next release.

> After changing the owner of /dev/console to the non-root user
> that is running the gui session, eject command starts to work.

Since I use a laptop this was fun.  Changed the owner to user:group and then
powered down.  The next day after bootup the owner had reverted back to
root:tty.

alan

> After changing the owner of /dev/console to the non-root user
> that is running the gui session, eject command starts to work.

Since I use a laptop this was fun.  Changed the owner to user:group and then
powered down.  The next day after bootup the owner had reverted back to
root:tty.

alan

Fixed in build 126.

Many thanks,
alan

(In reply to comment #16)

> > I think this is a bug in the OpenSolaris VirtualBox 3.0.8
> > release:
> > 
> >     http://forums.virtualbox.org/viewtopic.php?f=11&t=23392
> 
> I think you are probably right, although the symptoms are very similar - thanks
> for the reference Jürgen :-)

VirtualBox 3.0.10 is released and fixes this problem.

*** Bug 12566 has been marked as a duplicate of this bug. ***