Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #229468 > unrolled thread

SanDisk USB stick problem

Back to article view | Back to linux.debian.user

Contents

  SanDisk USB stick problem Fred <fred@blakemfg.com> - 2020-12-08 16:30 +0100
    Re: SanDisk USB stick problem steve <dlist@bluewin.ch> - 2020-12-08 16:50 +0100
      Re: SanDisk USB stick problem Fred <fred@blakemfg.com> - 2020-12-08 20:50 +0100
    Re: SanDisk USB stick problem l0f4r0@tuta.io - 2020-12-08 16:50 +0100
    Re: SanDisk USB stick problem Stefan Monnier <monnier@iro.umontreal.ca> - 2020-12-08 17:00 +0100
      Re: SanDisk USB stick problem Fred <fred@blakemfg.com> - 2020-12-08 20:50 +0100
        Re: SanDisk USB stick problem David Wright <deblis@lionunicorn.co.uk> - 2020-12-08 22:20 +0100
          Re: SanDisk USB stick problem Stefan Monnier <monnier@iro.umontreal.ca> - 2020-12-08 22:30 +0100
            Re: SanDisk USB stick problem Joe <joe@jretrading.com> - 2020-12-08 23:10 +0100
              Re: SanDisk USB stick problem Stefan Monnier <monnier@iro.umontreal.ca> - 2020-12-09 00:00 +0100
                Re: SanDisk USB stick problem David Wright <deblis@lionunicorn.co.uk> - 2020-12-09 00:40 +0100
            Re: SanDisk USB stick problem deloptes <deloptes@gmail.com> - 2020-12-08 23:20 +0100
              Re: SanDisk USB stick problem "James H. H. Lampert" <jamesl@touchtonecorp.com> - 2020-12-08 23:30 +0100
                Re: SanDisk USB stick problem deloptes <deloptes@gmail.com> - 2020-12-09 09:10 +0100
              Re: SanDisk USB stick problem <tomas@tuxteam.de> - 2020-12-09 10:00 +0100
                Re: SanDisk USB stick problem "Thomas Schmitt" <scdbackup@gmx.net> - 2020-12-09 10:20 +0100
                  Re: SanDisk USB stick problem <tomas@tuxteam.de> - 2020-12-09 12:20 +0100
                    Re: SanDisk USB stick problem Nicholas Geovanis <nickgeovanis@gmail.com> - 2020-12-09 22:20 +0100
                      Re: SanDisk USB stick problem <tomas@tuxteam.de> - 2020-12-09 22:30 +0100
                        Re: SanDisk USB stick problem Nicholas Geovanis <nickgeovanis@gmail.com> - 2020-12-09 22:40 +0100
                          Re: SanDisk USB stick problem <tomas@tuxteam.de> - 2020-12-09 23:20 +0100
            Re: SanDisk USB stick problem Tixy <tixy@yxit.co.uk> - 2020-12-08 23:50 +0100
            Re: SanDisk USB stick problem Fred <fred@blakemfg.com> - 2020-12-09 02:10 +0100
              Re: SanDisk USB stick problem Pankaj Jangid <pankaj@codeisgreat.org> - 2020-12-09 10:20 +0100
      Re: SanDisk USB stick problem Mike McClain <mike.junk.46@att.net> - 2020-12-09 02:10 +0100
    Re: SanDisk USB stick problem Henning Follmann <hfollmann@itcfollmann.com> - 2020-12-08 17:00 +0100
      Re: SanDisk USB stick problem Greg Wooledge <wooledg@eeg.ccf.org> - 2020-12-08 17:00 +0100
    Re: SanDisk USB stick problem David Christensen <dpchrist@holgerdanske.com> - 2020-12-09 05:40 +0100
      Re: SanDisk USB stick problem Andrei POPESCU <andreimpopescu@gmail.com> - 2020-12-09 11:30 +0100
      Re: SanDisk USB stick problem Celejar <celejar@gmail.com> - 2020-12-09 19:40 +0100
        Re: SanDisk USB stick problem Joe <joe@jretrading.com> - 2020-12-09 20:20 +0100
          Re: SanDisk USB stick problem Celejar <celejar@gmail.com> - 2020-12-09 21:30 +0100
            Re: SanDisk USB stick problem Joe <joe@jretrading.com> - 2020-12-09 21:40 +0100
              Re: SanDisk USB stick problem Tixy <tixy@yxit.co.uk> - 2020-12-10 09:30 +0100
                Re: SanDisk USB stick problem Joe <joe@jretrading.com> - 2020-12-10 09:40 +0100
                  Re: SanDisk USB stick problem Tixy <tixy@yxit.co.uk> - 2020-12-10 10:00 +0100
                    Re: SanDisk USB stick problem Tixy <tixy@yxit.co.uk> - 2020-12-10 10:10 +0100
                      Re: SanDisk USB stick problem <tomas@tuxteam.de> - 2020-12-10 11:00 +0100
                        Re: SanDisk USB stick problem Tixy <tixy@yxit.co.uk> - 2020-12-10 11:20 +0100
                          Re: SanDisk USB stick problem <tomas@tuxteam.de> - 2020-12-10 14:20 +0100
                          Re: SanDisk USB stick problem Stefan Monnier <monnier@iro.umontreal.ca> - 2020-12-10 20:10 +0100
                  Re: SanDisk USB stick problem David <bouncingcats@gmail.com> - 2020-12-10 10:20 +0100
                    Re: SanDisk USB stick problem Greg Wooledge <wooledg@eeg.ccf.org> - 2020-12-10 13:50 +0100
            Re: SanDisk USB stick problem Andrei POPESCU <andreimpopescu@gmail.com> - 2020-12-10 09:20 +0100
              Re: SanDisk USB stick problem Celejar <celejar@gmail.com> - 2020-12-10 18:40 +0100
              Re: SanDisk USB stick problem Michael Stone <mstone@debian.org> - 2020-12-10 20:10 +0100
          Re: SanDisk USB stick problem Andrei POPESCU <andreimpopescu@gmail.com> - 2020-12-10 09:20 +0100
      Re: SanDisk USB stick problem [solved] Fred <fred@blakemfg.com> - 2020-12-09 20:30 +0100
        Re: SanDisk USB stick problem [solved] Joe <joe@jretrading.com> - 2020-12-09 20:50 +0100
          Re: SanDisk USB stick problem [solved] Greg Wooledge <wooledg@eeg.ccf.org> - 2020-12-09 21:30 +0100
          Re: SanDisk USB stick problem [solved] Andrei POPESCU <andreimpopescu@gmail.com> - 2020-12-10 10:10 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#229592

[Multipart message — attachments visible in raw view] — view raw

On Wed, Dec 09, 2020 at 03:35:16PM -0600, Nicholas Geovanis wrote:
> On Wed, Dec 9, 2020, 3:28 PM <tomas@tuxteam.de> wrote:
> 
> > .......
> 
> 
> > > Instead I took it as a criticism of background processes in our society
> > and
> > > economy: mass-marketing and lack-of-choice (ineffective but enforced
> > > product buy-in, in this case).
> >
> > We are in violent agreement, then :)
> >
> 
> I just noticed that I called them "background processes" :-)
> You see, computing is a slowly-progressing disease :-)
> 
> Wouldn't it be more accurate to call those "Ring 0" processes or some such?
> Just a thought.
> What would Herr Doktor Karl Marx say?

Dialectical processes, I guess ;-P

(Ok, ok, I'll stop now).

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#229499

On Tue, 2020-12-08 at 16:21 -0500, Stefan Monnier wrote:
> > > > Others have suggested reformatting, but maybe a more
> > > > constructive path
> > > > forward is to return the bugger, complaining that it doesn't
> > > > work.
> > 
> > That seems like cutting off your nose to spite your face.
> > Presumably
> > the stick was bought for some purpose.
> 
> If you never complain&return those products broken-by-design, the
> companies will keep bringing them to the market.

But in this case the product isn't broken. The bundled Windows security
software on the USB stick is a red herring, it certainly doesn't
'break' the USB stick.

The OPs problem is he's trying to chown something on a FAT filesystem,
and the FAT format doesn't have the concept of different ownership.
Linux just sets an owner for the whole filesystem when it is mounted,
so to have different owner you would need to mount it differently.
(Don't ask me how, my GUI just mounts removable media when I click on
it with ownership by me, which is what I want).

-- 
Tixy

[toc] | [prev] | [next] | [standalone]

#229507

On 12/8/20 2:21 PM, Stefan Monnier wrote:
>>>> Others have suggested reformatting, but maybe a more constructive path
>>>> forward is to return the bugger, complaining that it doesn't work.
>>
>> That seems like cutting off your nose to spite your face. Presumably
>> the stick was bought for some purpose.
> 
> If you never complain&return those products broken-by-design, the
> companies will keep bringing them to the market.
> 
> 
>          Stefan
> 
I agree but taking something that doesn't work back to Walmart or other 
large company won't inform the manufacturer about the problem.  Walmart 
is going to throw it in the trash.

Best regards,
Fred

[toc] | [prev] | [next] | [standalone]

#229529

Fred <fred@blakemfg.com> writes:

>> If you never complain&return those products broken-by-design, the
>> companies will keep bringing them to the market.
>>          Stefan
>> 
> I agree but taking something that doesn't work back to Walmart or
> other large company won't inform the manufacturer about the problem.
> Walmart is going to throw it in the trash.

May be or may be not. We can't say. But every deviation from the normal
process is a big hassle for everyone in the supplychain. Imagine driving
in the wrong direction. Everyone feels the pain.

[toc] | [prev] | [next] | [standalone]

#229508

On Tue, Dec 08, 2020 at 10:53:16AM -0500, Stefan Monnier wrote:
> > I bought a SanDisk Cruzer Glide USB stick.  The fine print on the package
> > says it has SecureAccess software.  It is so secure it prevents me from
> > writing to it without running the included Bill Gates cancerous, virus
> > infested, scourge of the Earth software.
<snip>
> > Is there any way to disable or remove the SecureAccess software?
>
rm *    worked for me as root

> Others have suggested reformatting, but maybe a more constructive path
> forward is to return the bugger, complaining that it doesn't work.
>
Be sure they have a replacement before returning it.
I sent back 2 of their flash drives, different model, that were
running too hot to touch. They replaced 1 then said no more available
and that was a couple of months ago.

Be well,
Mike
--
Your talent is God's gift to you.
What you do with it is your gift back to God.

[toc] | [prev] | [next] | [standalone]

#229473

On Tue, Dec 08, 2020 at 08:29:47AM -0700, Fred wrote:
> Hello,
> 
> I bought a SanDisk Cruzer Glide USB stick.  The fine print on the package
> says it has SecureAccess software.  It is so secure it prevents me from
> writing to it without running the included Bill Gates cancerous, virus
> infested, scourge of the Earth software.a

Calm down!

> 
> fred@ragnok:/media/usb0$ ls -l
> total 8416
> drwxr-xr-x 2 root root   16384 Jul  9  2018 SanDiskSecureAccess
> -rwxr-xr-x 1 root root 8600360 Nov  4  2016 SanDiskSecureAccessV3.01_win.exe
> fred@ragnok:/media/usb0$

what does dmesg say when you plug this in?
I assume it will be just added as mass storage.

> 
> root@ragnok:/home/fred# chown fred /media/usb0
> chown: changing ownership of '/media/usb0': Operation not permitted
>

sudo chown fred /media/usb0

Would that work better?


> Attempts to add write permission are also denied.

again since root owns this. Did you use sudo or tried from
the root account?


> 
> Is there any way to disable or remove the SecureAccess software?
sure
rm -rf /media/usb0/SanDiskSecureAccess
rm /media/usb0/SanDiskSecureAccessV3.01_win.exe

again it's owned by root, so use sudo.

> Best regards,
> Fred
>


-H

-- 
Henning Follmann           | hfollmann@itcfollmann.com

[toc] | [prev] | [next] | [standalone]

#229475

On Tue, Dec 08, 2020 at 10:42:53AM -0500, Henning Follmann wrote:
> On Tue, Dec 08, 2020 at 08:29:47AM -0700, Fred wrote:
> > root@ragnok:/home/fred# chown fred /media/usb0
> > chown: changing ownership of '/media/usb0': Operation not permitted
> 
> sudo chown fred /media/usb0
> 
> Would that work better?

Not if there's a (V)FAT file system on the device.  Besides, the "root@"
at the start and the "#" at the end of the shell prompt would normally
mean they're already root.

Ownerships and permissions only work with Unix-type file systems, such
as ext4.

[toc] | [prev] | [next] | [standalone]

#229517

On 2020-12-08 07:29, Fred wrote:
> Hello,
> 
> I bought a SanDisk Cruzer Glide USB stick.  The fine print on the 
> package says it has SecureAccess software.  It is so secure it prevents 
> me from writing to it without running the included Bill Gates cancerous, 
> virus infested, scourge of the Earth software.
> 
> fred@ragnok:/media/usb0$ ls -l
> total 8416
> drwxr-xr-x 2 root root   16384 Jul  9  2018 SanDiskSecureAccess
> -rwxr-xr-x 1 root root 8600360 Nov  4  2016 
> SanDiskSecureAccessV3.01_win.exe
> fred@ragnok:/media/usb0$

I have many SanDisk USB flash drives, including several Cruzer Glide. 
They typically have an MBR partition scheme and one large VFAT or NTFS 
partition.


"SanDisk Secure Access" is optional Windows encryption software that is 
bundled with SanDisk USB flash drives.  Use it, ignore it, or delete it 
as you please; the software is not required to use the drive on any 
computer that supports the factory partitioning scheme and filesystem.


> root@ragnok:/home/fred# chown fred /media/usb0
> chown: changing ownership of '/media/usb0': Operation not permitted
> 
> Attempts to add write permission are also denied.

As you have not stated how you mounted the drive, I will assume that you 
plugged it in, an icon appeared on the desktop, you interacted with the 
icon, and the drive was mounted at /media/usb0.  If so, AIUI the various 
Debian desktops with automounting use FUSE.  The user account running 
the desktop and automounter will have whatever access controls that are 
supported by the filesystem and/or by FUSE.  But all other user 
accounts, including the root account (!), are denied access to the 
filesystem.  This is a security feature of FUSE.  See mount.fuse(8).


> Is there any way to disable or remove the SecureAccess software?

If you want to use the flash drive to move files between DOS, Windows, 
Linux, macOS, BSD, etc., leave the factory partitioning scheme and 
filesystem intact.  Use the desktop to mount and unmount the filesystem 
on the flash drive.  Use the file manager or a normal, non-root, 
terminal to delete or move aside the "Secure Access" stuff.


If you want to use the drive for some other purpose, such as burning a 
Debian Installer ISO image onto it, do not mount the drive using the 
desktop.  (You may have to disable the desktop automounting feature). 
Instead, open a terminal and use sudo(8) or su(1) to work with the drive.


David

[toc] | [prev] | [next] | [standalone]

#229536

[Multipart message — attachments visible in raw view] — view raw

On Ma, 08 dec 20, 20:39:35, David Christensen wrote:
> 
> If you want to use the drive for some other purpose, such as burning a
> Debian Installer ISO image onto it, do not mount the drive using the
> desktop.  (You may have to disable the desktop automounting feature).
> Instead, open a terminal and use sudo(8) or su(1) to work with the drive.

Or just eject / unmount / safe remove / etc. it before "burning" the 
image file to it.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#229575

On Tue, 8 Dec 2020 20:39:35 -0800
David Christensen <dpchrist@holgerdanske.com> wrote:

...

> As you have not stated how you mounted the drive, I will assume that you 
> plugged it in, an icon appeared on the desktop, you interacted with the 
> icon, and the drive was mounted at /media/usb0.  If so, AIUI the various 
> Debian desktops with automounting use FUSE.  The user account running 

They do? Do you have documentation of this? I can't find anything about
this in the documentation of, say, Xfce4's thunar-volman:

https://docs.xfce.org/xfce/thunar/using-removable-media

> the desktop and automounter will have whatever access controls that are 
> supported by the filesystem and/or by FUSE.  But all other user 
> accounts, including the root account (!), are denied access to the 
> filesystem.  This is a security feature of FUSE.  See mount.fuse(8).

Celejar

[toc] | [prev] | [next] | [standalone]

#229579

On Wed, 9 Dec 2020 13:35:57 -0500
Celejar <celejar@gmail.com> wrote:

> On Tue, 8 Dec 2020 20:39:35 -0800
> David Christensen <dpchrist@holgerdanske.com> wrote:
> 
> ...
> 
> > As you have not stated how you mounted the drive, I will assume
> > that you plugged it in, an icon appeared on the desktop, you
> > interacted with the icon, and the drive was mounted at /media/usb0.
> >  If so, AIUI the various Debian desktops with automounting use
> > FUSE.  The user account running   
> 
> They do? Do you have documentation of this? I can't find anything
> about this in the documentation of, say, Xfce4's thunar-volman:
> 
> https://docs.xfce.org/xfce/thunar/using-removable-media
> 
> > the desktop and automounter will have whatever access controls that
> > are supported by the filesystem and/or by FUSE.  But all other user 
> > accounts, including the root account (!), are denied access to the 
> > filesystem.  This is a security feature of FUSE.  See
> > mount.fuse(8).  
> 

I haven't investigated it thoroughly, but when I have casually checked
what is mounted, I see that any USB sticks plugged in are on fuse. Xfce
on sid, no usbmount, automounting done by systemd, by the way.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#229584

On Wed, 9 Dec 2020 19:10:42 +0000
Joe <joe@jretrading.com> wrote:

> On Wed, 9 Dec 2020 13:35:57 -0500
> Celejar <celejar@gmail.com> wrote:
> 
> > On Tue, 8 Dec 2020 20:39:35 -0800
> > David Christensen <dpchrist@holgerdanske.com> wrote:
> > 
> > ...
> > 
> > > As you have not stated how you mounted the drive, I will assume
> > > that you plugged it in, an icon appeared on the desktop, you
> > > interacted with the icon, and the drive was mounted at /media/usb0.
> > >  If so, AIUI the various Debian desktops with automounting use
> > > FUSE.  The user account running   
> > 
> > They do? Do you have documentation of this? I can't find anything
> > about this in the documentation of, say, Xfce4's thunar-volman:
> > 
> > https://docs.xfce.org/xfce/thunar/using-removable-media
> > 
> > > the desktop and automounter will have whatever access controls that
> > > are supported by the filesystem and/or by FUSE.  But all other user 
> > > accounts, including the root account (!), are denied access to the 
> > > filesystem.  This is a security feature of FUSE.  See
> > > mount.fuse(8).  
> > 
> 
> I haven't investigated it thoroughly, but when I have casually checked
> what is mounted, I see that any USB sticks plugged in are on fuse. Xfce
> on sid, no usbmount, automounting done by systemd, by the way.

Interesting. I haven't been using automounting, but I just enabled
Xfce's native automounting (Thunar / Edit / Preferences / Advanced /
Volume Management:Configure / Mount removable drives when hot-plugged)
and stuck in a flash drive. It gets mounted and I don't see any FUSE
involved:

~$ mount | grep sdb
/dev/sdb on /media/<username>/disk type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)

~$ mount | grep fuse
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

I'm curious about this because I can't imagine that FUSE performance is
as good as native, so why would automounters pay the performance
penalty of FUSE when native mounting would seem easy enough to do?

Celejar

[toc] | [prev] | [next] | [standalone]

#229587

On Wed, 9 Dec 2020 15:23:44 -0500
Celejar <celejar@gmail.com> wrote:

> On Wed, 9 Dec 2020 19:10:42 +0000
> Joe <joe@jretrading.com> wrote:
> 
> > On Wed, 9 Dec 2020 13:35:57 -0500
> > Celejar <celejar@gmail.com> wrote:
> >   
> > > On Tue, 8 Dec 2020 20:39:35 -0800
> > > David Christensen <dpchrist@holgerdanske.com> wrote:
> > > 
> > > ...
> > >   
> > > > As you have not stated how you mounted the drive, I will assume
> > > > that you plugged it in, an icon appeared on the desktop, you
> > > > interacted with the icon, and the drive was mounted at
> > > > /media/usb0. If so, AIUI the various Debian desktops with
> > > > automounting use FUSE.  The user account running     
> > > 
> > > They do? Do you have documentation of this? I can't find anything
> > > about this in the documentation of, say, Xfce4's thunar-volman:
> > > 
> > > https://docs.xfce.org/xfce/thunar/using-removable-media
> > >   
> > > > the desktop and automounter will have whatever access controls
> > > > that are supported by the filesystem and/or by FUSE.  But all
> > > > other user accounts, including the root account (!), are denied
> > > > access to the filesystem.  This is a security feature of FUSE.
> > > > See mount.fuse(8).    
> > >   
> > 
> > I haven't investigated it thoroughly, but when I have casually
> > checked what is mounted, I see that any USB sticks plugged in are
> > on fuse. Xfce on sid, no usbmount, automounting done by systemd, by
> > the way.  
> 
> Interesting. I haven't been using automounting, but I just enabled
> Xfce's native automounting (Thunar / Edit / Preferences / Advanced /
> Volume Management:Configure / Mount removable drives when hot-plugged)
> and stuck in a flash drive. It gets mounted and I don't see any FUSE
> involved:
> 
> ~$ mount | grep sdb
> /dev/sdb on /media/<username>/disk type vfat
> (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
> 
> ~$ mount | grep fuse
> fusectl on /sys/fs/fuse/connections type fusectl
> (rw,nosuid,nodev,noexec,relatime) portal on /run/user/1000/doc type
> fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
> 
> I'm curious about this because I can't imagine that FUSE performance
> is as good as native, so why would automounters pay the performance
> penalty of FUSE when native mounting would seem easy enough to do?
> 

With a quick trial, it depends on the filesystem. Many of my USB sticks
are FAT for portability, but they get mounted as fuseblk rather than
fat or vfat. Linux partitions are indeed mounted natively.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#229604

On Wed, 2020-12-09 at 20:34 +0000, Joe wrote:
> On Wed, 9 Dec 2020 15:23:44 -0500
> Celejar <celejar@gmail.com> wrote:
> 
[...]
> > Interesting. I haven't been using automounting, but I just enabled
> > Xfce's native automounting (Thunar / Edit / Preferences / Advanced
> > /
> > Volume Management:Configure / Mount removable drives when hot-
> > plugged)
> > and stuck in a flash drive. It gets mounted and I don't see any
> > FUSE
> > involved:
> > 
> > ~$ mount | grep sdb
> > /dev/sdb on /media/<username>/disk type vfat
> > (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,c
> > odepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,err
> > ors=remount-ro,uhelper=udisks2)
> > 
> > ~$ mount | grep fuse
> > fusectl on /sys/fs/fuse/connections type fusectl
> > (rw,nosuid,nodev,noexec,relatime) portal on /run/user/1000/doc type
> > fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
> > 
> > I'm curious about this because I can't imagine that FUSE
> > performance
> > is as good as native, so why would automounters pay the performance
> > penalty of FUSE when native mounting would seem easy enough to do?
> > 
> 
> With a quick trial, it depends on the filesystem. Many of my USB
> sticks
> are FAT for portability, but they get mounted as fuseblk rather than
> fat or vfat.

How are you mounting them? On Buster with LXDE desktop, USB sticks with
FAT filesystems don't get mounted by the GUI using fuse. I.e. my
experience matches Celejar's.

>  Linux partitions are indeed mounted natively.

Sorry, I don't understand what you mean by 'Linux partitions'. The only
two partitioning schemes I'm aware of are MBR and GPT neither of which
are Linux specific. And I can't see how the partitioning scheme would
affect how a FAT filesystem is mounted.

-- 
Tixy 

[toc] | [prev] | [next] | [standalone]

#229605

On Thu, 10 Dec 2020 08:26:40 +0000
Tixy <tixy@yxit.co.uk> wrote:


> 
> Sorry, I don't understand what you mean by 'Linux partitions'. 

Partitions containing Linux filesystems.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#229607

On Thu, 2020-12-10 at 08:35 +0000, Joe wrote:
> On Thu, 10 Dec 2020 08:26:40 +0000
> Tixy <tixy@yxit.co.uk> wrote:
> 
> 
> > Sorry, I don't understand what you mean by 'Linux partitions'. 
> 
> Partitions containing Linux filesystems.

OK, I guess you really meant filesystems supported by the Linux kernel,
because we're all talking about FAT here which certainly isn't a Linux
filesystems ;-)

Perhaps your USB stick is formatted with exFAT (which only gained
kernel support this year) and me and Celejar are using older
FAT/VFAT/FAT32 (I am). That would explain our different experiences
with fuse getting involved.

-- 
Tixy

[toc] | [prev] | [next] | [standalone]

#229608

On Thu, 2020-12-10 at 08:53 +0000, Tixy wrote:
> Perhaps your USB stick is formatted with exFAT (which only gained
> kernel support this year) and me and Celejar are using older
> FAT/VFAT/FAT32 (I am). That would explain our different experiences
> with fuse getting involved.

I just saw from you other replies that you're on Debian unstable, so
your kernel does have exFAT support. There must be something more
complicated going on then for your system to chose to use fuse to mount
the USB stick.

-- 
Tixy

[toc] | [prev] | [next] | [standalone]

#229617

[Multipart message — attachments visible in raw view] — view raw

On Thu, Dec 10, 2020 at 09:00:39AM +0000, Tixy wrote:
> On Thu, 2020-12-10 at 08:53 +0000, Tixy wrote:
> > Perhaps your USB stick is formatted with exFAT (which only gained
> > kernel support this year) and me and Celejar are using older
> > FAT/VFAT/FAT32 (I am). That would explain our different experiences
> > with fuse getting involved.
> 
> I just saw from you other replies that you're on Debian unstable, so
> your kernel does have exFAT support. There must be something more
> complicated going on then for your system to chose to use fuse to mount
> the USB stick.

I think the tencency is to mount untrusted file systems over FUSE,
due to the realisation that file system code wasn't designed with
malicious file system images in mind (remember? the time that code
got written, you had one hard disk firmly screwed into your beige
box computer), and on the hope that something exploding in user
space might be less devastating that having it explode in kernel
space...

For a rough impression, cf. e.g. here [1]

It's a timid first step to remove one of those skeletons from beneath
the bed (or a move towards a microkernel, depending on your current
mood ;-)

Cheers

[1] https://lwn.net/ml/linux-kernel/20180523234114.GA3434@thunk.org/

 - t

[toc] | [prev] | [next] | [standalone]

#229623

On Thu, 2020-12-10 at 10:56 +0100, tomas@tuxteam.de wrote:
> On Thu, Dec 10, 2020 at 09:00:39AM +0000, Tixy wrote:
> > On Thu, 2020-12-10 at 08:53 +0000, Tixy wrote:
> > > Perhaps your USB stick is formatted with exFAT (which only gained
> > > kernel support this year) and me and Celejar are using older
> > > FAT/VFAT/FAT32 (I am). That would explain our different
> > > experiences
> > > with fuse getting involved.
> > 
> > I just saw from you other replies that you're on Debian unstable,
> > so
> > your kernel does have exFAT support. There must be something more
> > complicated going on then for your system to chose to use fuse to
> > mount
> > the USB stick.
> 
> I think the tencency is to mount untrusted file systems over FUSE,
> due to the realisation that file system code wasn't designed with
> malicious file system images in mind (remember? the time that code
> got written, you had one hard disk firmly screwed into your beige
> box computer), and on the hope that something exploding in user
> space might be less devastating that having it explode in kernel
> space...

I can see there is good reasoning in that, perhaps that reasoning has
been implemented by the components in Debian Bullseye. Does seem a
little perverse though if it should be implemented just after Linux
gains an exFAT kernel driver, a filesystem that only really exists for
interoperability between devices (i.e. those that will be removable
media).

-- 
Tixy

[toc] | [prev] | [next] | [standalone]

#229631

[Multipart message — attachments visible in raw view] — view raw

On Thu, Dec 10, 2020 at 10:12:50AM +0000, Tixy wrote:
> On Thu, 2020-12-10 at 10:56 +0100, tomas@tuxteam.de wrote:

> > I think the tencency is to mount untrusted file systems over FUSE,
    [...]
> > due to the realisation that file system code wasn't designed with
> > malicious file system images in mind (remember? the time that code
> > got written, you had one hard disk firmly screwed into your beige
> > box computer), and on the hope that something exploding in user
> > space might be less devastating that having it explode in kernel
> > space...
> 
> I can see there is good reasoning in that, perhaps that reasoning has
> been implemented by the components in Debian Bullseye. Does seem a
> little perverse though if it should be implemented just after Linux
> gains an exFAT kernel driver, a filesystem that only really exists for
> interoperability between devices (i.e. those that will be removable
> media).

I'd think exFAT lands as well in libguestfs, where it can be used
by FUSE. Code is, after all, code ;-)

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web