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 3 of 3 — ← Prev page 1 2 [3]

#229643

> 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).

FWIW, the use of exFAT for filesystems which will basically never be
disconnected is very common in Android devices.


        Stefan

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

#229610

On Thu, 10 Dec 2020 at 19:35, Joe <joe@jretrading.com> 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.

I understand a 'Linux partition' to be one that has a
partition ID = 83h as discussed here:
https://en.wikipedia.org/wiki/Partition_type#PID_83h

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

#229630

On Thu, Dec 10, 2020 at 08:15:05PM +1100, David wrote:
> On Thu, 10 Dec 2020 at 19:35, Joe <joe@jretrading.com> 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.

That's what we are talking about, yes.

> I understand a 'Linux partition' to be one that has a
> partition ID = 83h as discussed here:

My understanding is ye olde partition type ID numbers are basically
irrelevant comments at this point.  You can set them so that you see a
nice human-readable type name when you run "fdisk -l" or the equivalent,
but it's not actually used for anything.  You could have a Linux ext4
file system on a partition that's marked as type "Microsoft basic data"
or anything else.

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

#229603

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

On Mi, 09 dec 20, 15:23:44, Celejar wrote:
>
> 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?

The ntfs-3g developers claim there is no significant penalty. Testing 
their claims would be difficult though, considering the kernel driver 
has limited functionality.

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

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

#229641

On Thu, 10 Dec 2020 10:17:41 +0200
Andrei POPESCU <andreimpopescu@gmail.com> wrote:

> On Mi, 09 dec 20, 15:23:44, Celejar wrote:
> >
> > 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?
> 
> The ntfs-3g developers claim there is no significant penalty. Testing 
> their claims would be difficult though, considering the kernel driver 
> has limited functionality.

I'm certainly not going to dispute the ntfs-3g developers, but I had
had in mind these comments of Linus Torvald that I had just come across:

"People who think that userspace filesystems are realistic for anything
but toys are just misguided.

fuse works fine if the thing being exported is some random low-use
interface to a fundamentally slow device. But for something like your
root filesystem? Nope. Not going to happen."

https://lkml.org/lkml/2011/6/9/462

Linus sometimes exaggerates, and in any event, external USB storage
devices are (generally) somewhere in between "your root filesystem" and
"some random low-use ..."

A quick search turns up this:

https://www.usenix.org/system/files/conference/fast17/fast17-vangoor.pdf

which I haven't had a chance to read.

Celejar

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

#229644

On Thu, Dec 10, 2020 at 10:17:41AM +0200, Andrei POPESCU wrote:
>On Mi, 09 dec 20, 15:23:44, Celejar wrote:
>> 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?
>
>The ntfs-3g developers claim there is no significant penalty. Testing
>their claims would be difficult though, considering the kernel driver
>has limited functionality.

For exfat, at least, the in-kernel driver is noticeably faster. From a 
reasonably fast drive I can get 600-700MByte/s with the kernel driver, 
and 400-500MByte/s with fuse. With a slower drive I can get about 
260MByte/s with kernel, 220MByte/s with fuse. Whether the difference is 
"significant" probably depends on how much data you're transferring and 
how long you're willing to wait.

In the past I've seen much larger differences for actual applications. I 
don't know if the fuse module has gotten faster or my quick copy test 
above doesn't adequately reflect real world performance. YMMV.

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

#229602

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

On Mi, 09 dec 20, 19:10:42, Joe wrote:
> 
> 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.

That is likely to happen for NTFS, because the kernel driver has no (or 
very limited?) write support.

For other filesystems the burden of proof is on you :)

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

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

#229580 — Re: SanDisk USB stick problem [solved]

On 12/8/20 9:39 PM, David Christensen wrote:
> 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.
> 
When I was denied permission to write a file to the device as a regular 
user I checked the permissions and then discovered root could not change 
them.  Being a hardware oriented person I was concerned the SecureAccess 
software needed to change a write protect bit in the device and decided 
to ask for help.  I should have tried writing to the device as root but 
being very busy I didn't.  It is writable by root and anyone can read it 
so there is no problem.
> 
>> 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).
> 
I do not use a DE.  Just openbox and xterm/command line.  Something 
automagically mounts USB devices.  Fuse is installed so maybe that is it.

> 
>> 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
> 
Thanks for the help.
Best regards,
Fred

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

#229582 — Re: SanDisk USB stick problem [solved]

On Wed, 9 Dec 2020 12:22:28 -0700
Fred <fred@blakemfg.com> wrote:


> When I was denied permission to write a file to the device as a
> regular user I checked the permissions and then discovered root could
> not change them.  Being a hardware oriented person I was concerned
> the SecureAccess software needed to change a write protect bit in the
> device and decided to ask for help.  I should have tried writing to
> the device as root but being very busy I didn't.  It is writable by
> root and anyone can read it so there is no problem.

I believe a mount point will always be owned by root, regardless of the
permissions of the underlying directory, because only root is allowed
to mount things. The device mounted on the mount point will normally be
owned by the logged-in user, unless /etc/fstab contains instructions to
the contrary. A device mounted while no user is logged in will be owned
by root (again, subject to fstab), something that usually happens if an
external drive has been left attached after shutting down. 

It's generally a bad idea to boot with an external medium attached,
unless it's bootable and you explicitly want to boot it. If it isn't
bootable, it will either be mounted as root (which may not prevent
other users writing to it) or the BIOS may hang.

-- 
Joe

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

#229585 — Re: SanDisk USB stick problem [solved]

On Wed, Dec 09, 2020 at 07:47:14PM +0000, Joe wrote:
> I believe a mount point will always be owned by root, regardless of the
> permissions of the underlying directory, because only root is allowed
> to mount things.

unicorn:~$ mkdir mtpt
unicorn:~$ ls -ld mtpt
drwxr-xr-x 2 greg greg 4096 Dec  9 15:22 mtpt/
unicorn:~$ sshfs remote: mtpt
unicorn:~$ ls -ld mtpt
drwxr-xr-x 1 greg greg 4096 Dec  6 23:09 mtpt/

FUSE changes a few things.

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

#229609 — Re: SanDisk USB stick problem [solved]

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

On Mi, 09 dec 20, 19:47:14, Joe wrote:
> 
> I believe a mount point will always be owned by root, regardless of the
> permissions of the underlying directory, 

Nitpick: in the relevant documentation a "mount point" is the underlying 
directory.

You're probably referring to the filesystem's root directory. Its 
permissions are managed the same as any other directory for "native" 
filesystems (ext*, xfs, etc.) and via mount options for FAT and NTFS.

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

[toc] | [prev] | [standalone]

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

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

csiph-web