On Wed, 2016-12-28 at 13:42 +0100, Pascal Hambourg wrote:
> Le 28/12/2016 à 11:19, Nimrod a écrit :
> >
> >> I guess I have to specify suitable permission in the above file. I
> >> tried with:
> >>
> >> ENV{ID_FS_USAGE}=="filesystem|other|crypto",
> >> ENV{UDISKS_FILESYSTEM_SHARED}="1", GROUP="use
Le 28/12/2016 à 11:19, Nimrod a écrit :
I guess I have to specify suitable permission in the above file. I
tried with:
ENV{ID_FS_USAGE}=="filesystem|other|crypto",
ENV{UDISKS_FILESYSTEM_SHARED}="1", GROUP="users", MODE="0660"
(on a single line), but it seems that GROUP and MODE are simply
ign
On Mon, 2016-12-26 at 22:16 +0100, Nimrod wrote:
> On Mon, 2016-12-26 at 18:29 +0100, Pascal Hambourg wrote:
>
> > Le 26/12/2016 à 17:28, Nimrod a écrit :
> > > On Sat, 2016-12-24 at 05:20 +0100, Michael Biebl wrote:
> > >
> > >> Does it help if you mount the cdrom as shared?
> > >> See https
On Mon, 2016-12-26 at 18:29 +0100, Pascal Hambourg wrote:
> Le 26/12/2016 à 17:28, Nimrod a écrit :
> > On Sat, 2016-12-24 at 05:20 +0100, Michael Biebl wrote:
> >
> >> Does it help if you mount the cdrom as shared?
> >> See https://udisks.freedesktop.org/docs/latest/udisks.8.html →
> >> UDISKS_FI
Le 26/12/2016 à 17:28, Nimrod a écrit :
On Sat, 2016-12-24 at 05:20 +0100, Michael Biebl wrote:
Does it help if you mount the cdrom as shared?
See https://udisks.freedesktop.org/docs/latest/udisks.8.html →
UDISKS_FILESYSTEM_SHARED
No, it doesn't. The disk is already mounted in a shared direct
On Sat, 2016-12-24 at 05:20 +0100, Michael Biebl wrote:
> Am 23.12.2016 um 18:54 schrieb Nimrod:
> > Hi,
> >
> > sorry for this trivial question, but I really tried to find an answer on
> > the web without any result.
> >
> > This is the issue: on a computer at home (shared among relatives, each
Am 23.12.2016 um 18:54 schrieb Nimrod:
> Hi,
>
> sorry for this trivial question, but I really tried to find an answer on
> the web without any result.
>
> This is the issue: on a computer at home (shared among relatives, each
> with his/her own account), the first user that logs in after boot lo
On Fri, 2016-12-23 at 23:16 +0100, Thomas Schmitt wrote:
> Hi,
>
> Nimrod wrote:
> > I see a "+" in your permission. What is that, and how could I get it
> > too?
>
> It indicates that there is a non-trivial ACL and that it is worth to run
> program getfacl to see all permissions.
>
> $
Hi,
Nimrod wrote:
> I see a "+" in your permission. What is that, and how could I get it too?
It indicates that there is a non-trivial ACL and that it is worth to run
program getfacl to see all permissions.
$ getfacl /dev/sr0
getfacl: Removing leading '/' from absolute path names
# fil
On Fri, 2016-12-23 at 20:54 +0100, Pascal Hambourg wrote:
> Le 23/12/2016 à 18:54, Nimrod a écrit :
> >
> > This is the issue: on a computer at home (shared among relatives, each
> > with his/her own account), the first user that logs in after boot locks
> > the cdrom drive, and any other user tha
Thanks for your kind answer, below is mine.
On Fri, 2016-12-23 at 20:30 +0100, Thomas Schmitt wrote:
> Hi,
>
> Nimrod wrote:
> > the first user that logs in after boot locks the cdrom
> > drive, and any other user that logs in can't eject the cdrom: only the first
> > user can eject it.
>
> Are
Le 23/12/2016 à 18:54, Nimrod a écrit :
This is the issue: on a computer at home (shared among relatives, each
with his/her own account), the first user that logs in after boot locks
the cdrom drive, and any other user that logs in can't eject the cdrom:
only the first user can eject it.
I sus
Hi,
Nimrod wrote:
> the first user that logs in after boot locks the cdrom
> drive, and any other user that logs in can't eject the cdrom: only the first
> user can eject it.
Are you sure that it is the existence of the a user's ACL permission
which prevents the other's from ejecting and not thei
13 matches
Mail list logo
