6

I'm running into trouble mounting an iPod on a newly upgraded Debian Squeeze. I suspect either a protocol has changed or I've tickled a bug, which I don't know where to report.

I'm trying to mount the iPod so that I have permission to read and write it. But my efforts come to nothing:

    $ sudo mount -v -t vfat -o uid=32074,gid=6202 /dev/sde2 /mnt/dev/sde2 on /mnt type vfat (rw,uid=32074,gid=6202)
    $ ls -l /mnt
    total 80
    drwxr-xr-x 2 root root 16384 Jan  1  2000 Calendars
    drwxr-xr-x 2 root root 16384 Jan  1  2000 Contacts
    drwxr-xr-x 2 root root 16384 Jan  1  2000 Notes
    drwxr-xr-x 3 root root 16384 Jun 23  2007 Photos
    drwxr-xr-x 6 root root 16384 Jun 19  2007 iPod_Control
    $ sudo umount /mnt
    $ sudo mount -v -t vfat -o uid=nr,gid=nr /dev/sde2 /mnt     
    /dev/sde2 on /mnt type vfat (rw,uid=32074,gid=6202)
    $ ls -l /mnt
    total 80
    drwxr-xr-x 2 root root 16384 Jan  1  2000 Calendars
    drwxr-xr-x 2 root root 16384 Jan  1  2000 Contacts
    drwxr-xr-x 2 root root 16384 Jan  1  2000 Notes
    drwxr-xr-x 3 root root 16384 Jun 23  2007 Photos
    drwxr-xr-x 6 root root 16384 Jun 19  2007 iPod_Control

As you see, I've tried both symbolic and numberic IDs, but the files persist in being owned by root (and only writable by root).

The IDs are really mine; I've had the UID since 1993.

$ id
uid=32074(nr) gid=6202(nr) groups=6202(nr),0(root),2(bin),4(adm),...

I've put an strace at http://pastebin.com/Xue2u9FZ, and the mount(2) call looks good:

mount("/dev/sde2", "/mnt", "vfat", MS_MGC_VAL, "uid=32074,gid=6202") = 0

Finally, here's my kernel version from uname -a:

Linux homedog 2.6.32-5-686 #1 SMP Mon Jun 13 04:13:06 UTC 2011 i686 GNU/Linux

Does anyone know if

  • I should be doing something different, or
  • If there is a workaround, or
  • If this is a bug, where it should be reported?
Improve this question
11
  • Do those UIDs and GIDs (31074 and 6202) actually exist on the system? If you type 'id' does it show that you have that UID and GID?
    – Jeremy Visser
    Sep 14, 2011 at 3:40
  • I apologize - I would like to add a comment but I do not see the link as I usually do. Another suggestion I'd like to add is watching the output of 'strace' on this command - that can be very enlightening of what's going on under the hood. But I agree with the first commenter - check to make sure those UID and GIDs exist. (Although, I believe mount complains if they don't.) Let me give this some more thought.
    – Larold
    Sep 14, 2011 at 3:53
  • @Jeremy: yep, thanks. Long story, but I've updated the question.
    – Norman Ramsey
    Sep 14, 2011 at 4:30
  • IDs checked, strace provided, also gave kernel version. If you have some ideas I'll be delighted.
    – Norman Ramsey
    Sep 14, 2011 at 4:37
  • Ok - strace shows nothing unusual. Try this - it's a super-duper long shot, but I don't believe it will hurt. Instead of 'uid' and 'gid' arguments, try 'setuid' and 'setgid'. The reason I suggest this is that for a separate filesystem type, these options control the owner/group of files and directories WITHIN the filesystem, not just the root of the fs itself. MAYBE (but I don't ever remember this being the case), you'll get epic-lucky and those options actually do work for vfat. I'm 99.99% doubtful, but always worth a shot. I'll try to think of anything else.
    – Larold
    Sep 14, 2011 at 5:26

1 Answer 1

Reset to default
0

Rebooting the machine made the problem go away.

I think I will leave the question since it seems that it does in fact show how to mount a vfat drive on Linux with ownership other than root. But if someone thinks I should delete the question please let me know.

Improve this answer
1
  • I would also suggest looking at pmount(1), which allows for normal users to mount removable drives.
    – ptman
    Aug 9, 2013 at 6:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .