[GRLUG] Firefox on an external drive

[Bob Kline]

On Sun, May 17, 2009 at 12:55 PM, Tom Warren
<tomewarren+grlug at gmail.com<tomewarren%2Bgrlug at gmail.com>
> wrote:

>
>
>
> On Sun, May 17, 2009 at 12:28 PM, Bob Kline <bob.kline at gmail.com> wrote:
>
>>
>>
>> On Sun, May 17, 2009 at 12:17 PM, Michael Mol <mikemol at gmail.com> wrote:
>>
>>> On Sun, May 17, 2009 at 12:00 PM, Bob Kline <bob.kline at gmail.com> wrote:
>>> > On Sat, May 16, 2009 at 10:44 PM, Michael Mol <mikemol at gmail.com>
>>> wrote:
>>> >> On Sat, May 16, 2009 at 10:43 AM, Bob Kline <bob.kline at gmail.com>
>>> wrote:
>>> >> > 755  root root
>>> >> >
>>> >> > I changed the owner to myself, and
>>> >> > nothing changes.
>>> >> >
>>> >> > But then, I can look at any other directory
>>> >> > in root with similar permissions.  Just not the
>>> >> > external drive.
>>> >>
>>> >> When you mount something, the mount permissions override that of the
>>> >> mount point.  Try setting the user and permissions for the mount as
>>> >> part your parameters to the mount command.
>>> >
>>> > Would that be any different than just setting
>>> > them afterwards?
>>> >
>>> > Anyway, I tried the mount as:
>>> >
>>> > mount -t ext3 -o owner,group /dev/sdb7 /disk2
>>> >
>>> > I see the same behavior as before:  I can view
>>> > items within /disk2, but not the contents of /disk2.
>>> >
>>> > And of course the contents of any directory on
>>> > the primary drive.
>>> >
>>>
>>> In a perfect and intuitive world with perfect and intuitive software?
>>> No.  At this point, I'm trying to exhaust all possible options,
>>> keeping in mind the different systems involved and where there might
>>> be failures in their interaction.
>>>
>>> Try setting the owner and group of the mount by uid and gid
>>> respectively, rather than by name.
>>>
>>> If that doesn't work, try adding the mount to fstab with the options
>>> "user,noauto,exec".  Then, as the user you want to have access to the
>>> data, try "mount /disk2", and see if Firefox can see the directory
>>> contents.
>>>
>>> If *that* doesn't work, then it's probably not a permissions issue at
>>> all; Something in Firefox might be disallowing enumeration of mount
>>> point roots as a security feature.  You'd have to dig through
>>> about:config to find it, if it's configurable.
>>>
>>> Another observation: Since this is an external disk, it might be
>>> worthwhile for you to use the persistent-naming schemes that seem to
>>> be part of udev now; Take a look under /dev/disk, and see if any of
>>> those symlinks device nodes will continue to refer to the disk you
>>> want to access under circumstances which change the device-devicenode
>>> mapping. (Such as, for example, if you were to add a SATA disk; the
>>> external USB or firewire disks would get moved to sdc or sdd, and the
>>> SATA disk would be sdb.)
>>>
>>>
>>
>> Re "all possible options,"   I'll play around
>> with this some over time.   I suppose Firefox
>> could be doing this on purpose, and it might
>> be stated so in some documentation.  As far
>> as I can see,  the fact that konqueror works
>> and Firefox doesn't suggests as much.
>>
>> I'll be back if anything changes.
>>
>> BTW, anyone else see this same phenomena?
>>
>>    -- Bob
>>
>>
>>
>>
>>
>> _______________________________________________
>> grlug mailing list
>> grlug at grlug.org
>> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>>
>
>
> other::r-w
>
> That's the key to your problem, a directory needs execute permission for
> the user to list the contents of the directory. I am not sure how Konqueror
> is getting around this (part of the root group maybe?), once you set that to
> r-x I bet Firefox will be able to list the contents of the directory.
>
>
>
> Tom
>
>
>
I used chmod to change the permissions on
disk2 to 777.  No luck.

The other directories in the root have
permissions 755, and Firefox lists their
contents, so it still seems to come down
to something about the new drive.

    -- Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shinobu.grlug.org/pipermail/grlug/attachments/20090517/c35a768a/attachment-0001.htm