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

Groups > comp.os.linux.hardware > #1507 > unrolled thread

WD Passport commands

Back to article view | Back to comp.os.linux.hardware

Contents

  WD Passport commands Haines Brown <haines@histomat.net> - 2012-11-05 23:08 -0500
    Re: WD Passport commands Richard Kettlewell <rjk@greenend.org.uk> - 2012-11-06 08:50 +0000
    Re: WD Passport commands Haines Brown <haines@histomat.net> - 2012-11-16 15:31 -0500
      Re: WD Passport commands Richard Kettlewell <rjk@greenend.org.uk> - 2012-11-16 21:32 +0000
        Re: WD Passport commands Haines Brown <haines@histomat.net> - 2012-11-17 05:57 -0500
          Re: WD Passport commands J G Miller <miller@yoyo.ORG> - 2012-11-17 13:44 +0000
            Re: WD Passport commands Aragorn <stryder@telenet.be.invalid> - 2012-11-17 19:19 +0100
            Re: WD Passport commands Haines Brown <haines@histomat.net> - 2012-11-17 13:25 -0500
              Re: WD Passport commands Richard Kettlewell <rjk@greenend.org.uk> - 2012-11-17 20:30 +0000
                Re: WD Passport commands Haines Brown <haines@histomat.net> - 2012-11-20 05:03 -0500
                  Re: WD Passport commands Richard Kettlewell <rjk@greenend.org.uk> - 2012-11-20 10:25 +0000
                    Re: WD Passport commands Haines Brown <haines@histomat.net> - 2012-11-20 11:27 -0500
              Re: WD Passport commands J G Miller <miller@yoyo.ORG> - 2012-11-18 18:16 +0000
              Re: WD Passport commands Bill Marcum <bill@nowhere.invalid> - 2012-11-19 03:03 -0500

#1507 — WD Passport commands

I've not had this problem with the Western Digital Passports before, but
a new one (WXQ1C5219385) is not being cooperative.  

The first problem is looking at /var/log/messages to get the drive's
UUID: 

  $ tail -f /var/log/messages
  ... scsi 28:0:0:0: Direct-Access     WD       My Passport 0748 1015 PQ: 0 ANSI: 6
  ... scsi 28:0:0:1: Enclosure         WD       SES Device       1015 PQ: 0 ANSI: 6
  ... sd 28:0:0:0: Attached scsi generic sg3 type 0
  ... sd 28:0:0:0: Attached scsi generic sg3 type 0
  ... ses 28:0:0:1: Attached Enclosure device
  ... ses 28:0:0:1: Attached scsi generic sg4 type 13
  ... sd 28:0:0:0: [sdc] 1953458176 512-byte logical blocks: (1.00 TB/931 GiB)
  ... sd 28:0:0:0: [sdc] Write Protect is off
  ... sdc: sdc1
  ... sd 28:0:0:0: [sdc] Attached SCSI disk
  usbmount[18281]: /dev/sdc does not contain a filesystem or disklabel

I would expect an added line something like: 

   usbmount[11090]: executing command: mount -U 8A2CF4F62CF4DE5F

I suppose usbmount can't mount because there's no UUID entry in
fstab. So I thought if I mounted the device manually, I might then get
the UUID. So I did:

  $ dmesg
  ...
  ... scsi 28:0:0:0: Direct-Access WD My Passport 0748 1015 PQ: 0 ANSI: 6
  ... scsi 28:0:0:1: Enclosure  WD SES Device 1015 PQ: 0 ANSI: 6
  ...
  ... sd 28:0:0:0: [sdc] Assuming drive cache: write through
  ... sdc: sdc1
  ...

  # mount -t ntfs /dev/sdc1 /media/backup

  $ mount
  ...
  /dev/sdc1 on /media/backup type fuseblk 
            (rw,allow_other,blksize=4096,default_permissions)

This succeeded to the extent I can write a file to the media and save
it. However, still no UUID reported. How do I get the UUID?

Once mounted manually I see that the WD Passport holds a collection of
directories:

  $ ls -la /media/backups
  ls: cannot access Locale: Input/output error
  ls: cannot access My Passport Apps for Mac: Input/output error
  ls: cannot access User Manuals: Input/output error
  ls: cannot access WD Apps for Windows: Input/output error
  total 13
  drwxrwxrwx  1 haines root   4096 Nov  5 22:28 .
  drwxr-xr-x 14 haines haines 4096 Jul 23  2011 ..
  d--------   root root       4096 Sep 30 21:24 Extras
  d?????????  ? ?      ?         ?            ? Locale
  -rw-r--r--  1 haines haines   25 Nov  5 22:28 MyInfo
  d?????????  ? ?      ?         ?            ? My Passport Apps for Mac
  d---------  1 root   root      0 Sep  2  2011 System Volume Information
  d?????????  ? ?      ?         ?            ? User Manuals
  d?????????  ? ?      ?         ?            ? WD Apps for Windows

The "MyInfo" file is the test file I wrote to the media.

The filesystem is NTFS, and so I thought I would have no problem using
cd, rm, and rmdir commands to get rid of these excess
directories. However, not so:

  $ cd Locale
  bash: cd: Locale: Input/output error

  # cd "System Volume Information"
  sudo: cd: command not found

How do I get rid of them?

Haines Brown
  

[toc] | [next] | [standalone]

#1508

Haines Brown <haines@histomat.net> writes:
> This succeeded to the extent I can write a file to the media and save
> it. However, still no UUID reported. How do I get the UUID?

Have you tried blkid?

-- 
http://www.greenend.org.uk/rjk/

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

#1527

I used mkntfs to reformat a WD Passport. Its size is 1 Tb, and it took
10 hours to reformat. 

I found that reformatting changes the UUID. But when I provided the new
UUID to fstab, it automounts just fine. It is mounted on a directory
owned by user, but it automatically reverts to root. 

Is there any good reason why I should not make its parent directory
(/media) owned by owner rather than root?

As a sanity check, I created a file in its partition. But it looks like
this:

    -rwxrwxrwx  1 root   root    5 Nov 16 14:56 test

I certainly did not want it to be executable or owned by root, but the
commands chown and chmod have no effect on it.

Haines Brown 

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

#1528

Haines Brown <haines@histomat.net> writes:
> I used mkntfs to reformat a WD Passport. Its size is 1 Tb, and it took
> 10 hours to reformat.
>
> I found that reformatting changes the UUID. But when I provided the
> new UUID to fstab, it automounts just fine. It is mounted on a
> directory owned by user, but it automatically reverts to root.
>
> Is there any good reason why I should not make its parent directory
> (/media) owned by owner rather than root?

"Owned by owner" doesn't make any sense.  At any rate messing with the
permissions on /media won't help.

> As a sanity check, I created a file in its partition. But it looks like
> this:
>
>     -rwxrwxrwx  1 root   root    5 Nov 16 14:56 test
>
> I certainly did not want it to be executable or owned by root, but the
> commands chown and chmod have no effect on it.

I believe a fstab line with uid= and gid= settings will let you control
this.  Also ntfs-3g supports user mapping (according to its
documentation; I've never tried).

However, if what you want is normal Unix permissions then NTFS is a
completely perverse choice.  It is not a UNix filesystem and will not
behave like one.  Use ext3 or something instead.

-- 
http://www.greenend.org.uk/rjk/

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

#1529

 
Thanks, Richard.

Richard Kettlewell <rjk@greenend.org.uk> writes:

> "Owned by owner" doesn't make any sense.  At any rate messing with the
> permissions on /media won't help.

Sorry, meant "owned by user". 

>> As a sanity check, I created a file in its partition. But it looks like
>> this:
>>
>>     -rwxrwxrwx  1 root   root    5 Nov 16 14:56 test
>>
>> I certainly did not want it to be executable or owned by root, but the
>> commands chown and chmod have no effect on it.
>
> I believe a fstab line with uid= and gid= settings will let you control
> this.  Also ntfs-3g supports user mapping (according to its
> documentation; I've never tried).

Tried uid and gid didn't help. 

> However, if what you want is normal Unix permissions then NTFS is a
> completely perverse choice.  It is not a UNix filesystem and will not
> behave like one.  Use ext3 or something instead.

Yes, I see I'm fighting the wind. The drive is for backups, and it is
hard to imagine a scenario in which I needed to extract files from the
archive in a DOS environment. I'll take you advice and format ext3.

Haines 

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

#1530

On Saturday, November 17th, 2012, at 05:57:36h -0500, Haines Brown wrote:

> Tried uid and gid didn't help.

You need something like this in your /etc/fstab

/dev/sda1       /mnt/C          ntfs    defaults,gid=46,locale=en_US.utf8,umask=022             0 0

where the numbers specfied for gid and uid and found from /etc/passwd and /etc/group.

Do not forget that after changing the fstab you need to remount the file
system in order to see the change.

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

#1531

On Saturday 17 November 2012 14:44, J G Miller conveyed the following to 
comp.os.linux.hardware...

> On Saturday, November 17th, 2012, at 05:57:36h -0500, Haines Brown
> wrote:
> 
>> Tried uid and gid didn't help.
> 
> You need something like this in your /etc/fstab
> 
> /dev/sda1       /mnt/C          ntfs   
> defaults,gid=46,locale=en_US.utf8,umask=022             0 0
> 
> where the numbers specfied for gid and uid and found from /etc/passwd
> and /etc/group.

Just for the record, if the filesystem is to be mounted under his 
"normal" UID and GID, then he can also ascertain this information by 
using the command...

   id

> Do not forget that after changing the fstab you need to remount the
> file system in order to see the change.

Yes.  They are mount time options and /etc/fstab is only read when the 
filesystem is (re)mounted.

-- 
= Aragorn =
(registered GNU/Linux user #223157)

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

#1532

J G Miller <miller@yoyo.ORG> writes:

> On Saturday, November 17th, 2012, at 05:57:36h -0500, Haines Brown wrote:
>
>> Tried uid and gid didn't help.
>
> You need something like this in your /etc/fstab
>
> /dev/sda1       /mnt/C          ntfs    defaults,gid=46,locale=en_US.utf8,umask=022             0 0
>
> where the numbers specfied for gid and uid and found from /etc/passwd and /etc/group.

Thanks, I had something like that for another NTFS drive and have not
experienced problems:

  UUID=8A2CF4F62CF4DE5F /media/backup ntfs-3g 
      noauto,user,uid=1000,gid=1000  0 0
  
I finally concluded I was unnecessarily beating my head against the wall
with this Passport (it took 10 hours to reformat it NTFS!) and so I
decided reformat it this morning as EXT3. This took ten minutes and
everything is now working with this fstab entry:

  UUID=231f5918-47b5-4ed1-ae03-c15916fe91f4 /media/backup ext3
    noauto,user,uid=1000,gid=1000 0 0

Interesting, reformating changes the device UUID.

I still have a problem I didn't have in earlier kernels, which is that
when user writes a file to this device, the file ends being owned by
root, not by user. Only now with EXT3 I can run chown on it to change
the owner. But I'd just a soon a file written by user keep user's
ownership. Years ago I think I simply changed owner of the dev file or
something like that to give user free access to a device, but surely
that's not right.

Haines
 

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

#1533

Haines Brown <haines@histomat.net> writes:
> I finally concluded I was unnecessarily beating my head against the wall
> with this Passport (it took 10 hours to reformat it NTFS!) and so I
> decided reformat it this morning as EXT3. This took ten minutes and
> everything is now working with this fstab entry:
>
>   UUID=231f5918-47b5-4ed1-ae03-c15916fe91f4 /media/backup ext3
>     noauto,user,uid=1000,gid=1000 0 0

Overriding uid and gid on a proper Unix fs would be a weird thing to do,
though they’re not documented as support for ext[234] in any case.

> Interesting, reformating changes the device UUID.

The UUID is part of the filesystem, not a property of the physical
device.

> I still have a problem I didn't have in earlier kernels, which is that
> when user writes a file to this device, the file ends being owned by
> root, not by user. Only now with EXT3 I can run chown on it to change
> the owner. But I'd just a soon a file written by user keep user's
> ownership. Years ago I think I simply changed owner of the dev file or
> something like that to give user free access to a device, but surely
> that's not right.

Indeed, that’s not right at all.  Can you show a transcript of this
happening (use id to check UID/GID, touch to create a file, ls -l to
show what it turns up as)?

-- 
http://www.greenend.org.uk/rjk/

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

#1546

Richard Kettlewell <rjk@greenend.org.uk> writes:

> Haines Brown <haines@histomat.net> writes:

>> I still have a problem I didn't have in earlier kernels, which is that
>> when user writes a file to this device, the file ends being owned by
>> root, not by user. Only now with EXT3 I can run chown on it to change
>> the owner. But I'd just a soon a file written by user keep user's
>> ownership. Years ago I think I simply changed owner of the dev file or
>> something like that to give user free access to a device, but surely
>> that's not right.
>
> Indeed, that’s not right at all.  Can you show a transcript of this
> happening (use id to check UID/GID, touch to create a file, ls -l to
> show what it turns up as)?

Sorry for the delated response. I now no longer have the problem because
I made user owner of the mount point for the external device, even
though I had the impression this not supposed to be done.

I also have the impression that the use of uid and gid in the fstab line
is only for NTFS, not for EXT3. I suspect using them for EXT3 is why
user had trouble writting to the device.

Haines Brown

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

#1547

Haines Brown <haines@histomat.net> writes:
> Richard Kettlewell <rjk@greenend.org.uk> writes:
>> Haines Brown <haines@histomat.net> writes:

>>> I still have a problem I didn't have in earlier kernels, which is that
>>> when user writes a file to this device, the file ends being owned by
>>> root, not by user. Only now with EXT3 I can run chown on it to change
>>> the owner. But I'd just a soon a file written by user keep user's
>>> ownership. Years ago I think I simply changed owner of the dev file or
>>> something like that to give user free access to a device, but surely
>>> that's not right.
>>
>> Indeed, that’s not right at all.  Can you show a transcript of this
>> happening (use id to check UID/GID, touch to create a file, ls -l to
>> show what it turns up as)?
>
> Sorry for the delated response. I now no longer have the problem because
> I made user owner of the mount point for the external device, even
> though I had the impression this not supposed to be done.

Changing the permissions on the “outside” - i.e. before mounting - will
make no difference once the filesystem is mounted.

Changing the permissions on the inside - i.e. after mounting - is a
perfectly sensible thing to do.  It won’t affect the owner field of
files in the filesystem though (but it can affect the group).

> I also have the impression that the use of uid and gid in the fstab line
> is only for NTFS, not for EXT3. I suspect using them for EXT3 is why
> user had trouble writting to the device.

In fact it turns out that ext3 refuses to mount if you supply uid= or
gid= options.  If you had these present then I doubt that you had the
device mounted at all.

-- 
http://www.greenend.org.uk/rjk/

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

#1549

Richard Kettlewell <rjk@greenend.org.uk> writes:

> Haines Brown <haines@histomat.net> writes:
>> Richard Kettlewell <rjk@greenend.org.uk> writes:
> Changing the permissions on the “outside” - i.e. before mounting - will
> make no difference once the filesystem is mounted.
>
> Changing the permissions on the inside - i.e. after mounting - is a
> perfectly sensible thing to do.  It won’t affect the owner field of
> files in the filesystem though (but it can affect the group).

Thank you. I don't know why I had the idea this should not be done under
Linux. 

Haines Brown

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

#1534

On Saturday, November 17th, 2012, at 13:25:58h -0500, Haines Brown wrote:
  
> I finally concluded I was unnecessarily beating my head against the wall
> with this Passport (it took 10 hours to reformat it NTFS!)

10 hours sounds excessive -- was this done from GNU/Linux or Windoze
and did you definitely have the disk plugged in via a USB 2.0
socket rather than an old USB 1.0 socket?

Very occasionally plugging in a USB 2.0 disk into a USB 2.0
socket on the PC does not work quite right and the speed is
dropped down to the USB 1.0 level.

The easy way to check is to run dmesg immediately after plugging
in the device and checking to say that dmesg says "new high speed USB device"
and then after a few minute to check again with dmesg to see that there
are no messages indicating some sort of problem on the USB link and the
dreaded message along the lines of dropping speed down.

> Interesting, reformating changes the device UUID.

The correct term is no formatting.  Formatting is a low leve
operation on the disk, and what you are doing with mkfs or
mknfs is *MaKeing* a file system on the specified partion /dev/sdc1
or whatever.

By default, when you invoke mkfs, it generates a new UUID for
the file system on the specified partition.  If you ever juggle
around your disks changing the root / and/or possibly separate
file system for /usr/share and you are using Grub 2, you have
to worry about the UUID, because the Grub 2 configuration file
contains these specific UUIDs.

> I still have a problem I didn't have in earlier kernels, which is that
> when user writes a file to this device, the file ends being owned by
> root, not by user. 

Because you have forced it to be by the use of the uid (and for group, gid)
parameters on the mount command (either command line or in /etc/fstab).

> But I'd just a soon a file written by user keep user's
> ownership.

So do no specify the uid for the mount command.  Consider using
the umask and gmask though if you want to force the files to
be readable or non-readable to others, independent of the 
particular user's umask setting.

> Years ago I think I simply changed owner of the dev file or
> something like that to give user free access to a device, but surely
> that's not right.

It is not a case of "right" but what is appropriate for your particular
machine and usage pattern.  If there is only ever a single user, then
the flexible way is to either use the GiveDevices / TakeDevices script
method related to the display manager login or to look at PolicyKit
for setting permissions per user login.

openSuSE used to use its own system wide script based method (via cron if I
recall correctly) of ensuring the default permissions on important files
and devices, I do not know if they still have that, or if they have moved
on to Policy Kit for everything.

Have a look at  <ttps://wiki.archlinux.org/index.php/PolicyKit>
and in particular 5.2 "Mounting USB Drives"

I suspect that Policy Kit is too much for the type of system which
you are running since its main audience is multi user systems, or
maybe you do in fact have lots of different research workers logging
in to your machines?  ;)

There is also at the desktop level (as opposed to desktop independent Policy Kit
which applies whether the login is a terminal session or X session) the package
called Console Kit which works via dbus.  I think it should be possible to
configure Console Kit to set up permissions on devices and related USB drives 
via its configuration files and an appropriate script.

But Console Kit is going away, so it is best not to pursue that option.
It will be replaced by a feature of systemd, and the mere mention of
that package (good in theory, not so good in implementation) may elicit
some vituperative remarks from others on "why systemd is a bad thing".

Of course for a single default user system you can always hard code the
device ownership and permissions for USB mount points via udev.

So the usual problem on a GNU/Linux system is not a case of being
unable to make something happen, but first choosing the most appropriate
way for the particular machine and the way in which it is used way.

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

#1541

On 11/17/2012 01:25 PM, Haines Brown wrote:
>
> I still have a problem I didn't have in earlier kernels, which is that
> when user writes a file to this device, the file ends being owned by
> root, not by user. Only now with EXT3 I can run chown on it to change
> the owner. But I'd just a soon a file written by user keep user's
> ownership. Years ago I think I simply changed owner of the dev file or
> something like that to give user free access to a device, but surely
> that's not right.
>
Make sure the directories don't have setuid or setgid permissions.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.hardware

csiph-web