Hi all,

I thought I'd got permissions issues under control by now, but it seems I now have a problem that I cannot suss out.

I'm trying to restore an image from an external usb drive to an SD card using 'dd' within a terminal on a netbook running Ubuntu.

dd: opening /dev/sdc: Permission denied

Not very informative (is it ever?)

I'm prefixing the command with 'sudo' and the only other thing I can think of is it's a machine name issue, so I've done

but to no avail. Still get same message. Any ideas?

I'm pretty certain I could fix this by running as proper Root off a Knoppix live CD or similar, but am curious to know what's scuppering my attempts with Ubuntu (which I admit is not a distro I'm familiar with).

Wild guess: Did you make any changes to your /etc/sudoers file?

In any case, for what you've said, I think the following might be an interesting read for you: https://help.ubuntu.com/community/Sudoers

No I haven't and it isn't. I really is just an academic question since I could easily do the job as 'proper Root' off a live CD.
I'm really only asking out of idle curiosity.

Um, /dev/sdc is the WHOLE drive, not a partition on the drive, nor even a file on the drive. So were you asking dd to image your third drive? (e.g. dd if=/dev/sdc of=dev_c.img bs=2048)? From your question, it seems to me that you want something like sudo dd if=saved.img of=/dev/sdc bs=2048

Note that, for this to work, /dev/sdc must be unmounted. So, if your system automatically mounts USB drives for you, do a sudo umount /dev/sdc before you try the dd command. (dd won't write to device mounted as writable since the result of doing so is unpredictable, and usually not desired.)

It's because I understood your question was academic and because you said you could do the job as 'proper root' I mentioned the /etc/sudoers file. Because with it you can control just how privileged your sudo-issuing users are, from just about the exact same as 'proper root' ('su' and 'su -' are not the same...) to just about a completelly unprivileged user. But hey, if that doesn't interest you, then it just doesn't.

Anyway, PTrenholme's answer above seems to be much more useful to actually solve the concrete issue you presented on your first post.

Sorry, it's a bit late in the evening in my local timezone here so I'm not as awake as I was earlier.
Yes, I'm aware /dev/sdc is the WHOLE (SD card in this instance) drive - although it's currently got 2 partitions on it (sdc1 & sdc2) I'm quite happy to have both sdc1 and sdc2 permanently trashed as a result of being over-written by the operation I'm attempting to carry out - in fact that is an inevitable consequence.
I'm attempting to transfer an entire, working image over to this aforementioned SD card from a single .gz file which resides on a partition on an external usb drive.
As an aside, I've just realized how incredibly hard it is to describe this simple operation unambiguously! Hats off to supreme masters of precision technical writing like Kernighan & Richie! This is SO tough explain!!!

Hey, no offense, man.
I appreciate you are only trying to help. It's just that I prefer something truly powerful like Knoppix or Slax that doesn't treat me like a baby and therefore behaves like I need protecting from myself.
Distros like those just do my head in for the same reason I avoid e-friendly detergents and prefer bleaches like Harpic. They get the job done but if I burn myself I have only myself to blame! Being a bit old-fashioned, that's the way I like it.

Hey CC, did you read the "note" at the end of my post, above? From the location you posted (/media/...) in your initial post in this thread (unless that was the external drive you referenced in post #6) that is a location typically used by distributions that automount USB [and other] drives.)

Rather than struggling to "clearly describe" your problem, why not just show us the commands you entered, in the order you used them, with comments describing what the (exact) arguments you used represent. (I.e., run the commands again, copy them from the terminal window, and past them (between [code] tags) here. Then add the argument descriptions.)

<edit>
Reading again your reply to my post, perhaps the command you want is: gunzip -kcq {image_file} 2>/dev/null | dd of=/dev/sdc bs={1024} where, of course, the block size should be whatever you used when you created the image.

But, if that's not the problem, please follow my suggestion in the second paragraph.

Oh, and I hope you read this Sunday, after a good night's sleep - it's still quite early here...
</edit>

I fully admit I'm not happy with this sudo business. I much prefer distros where I'm in Root from the get-go. For example, in this Ubuntu installation under discussion, if I enter "sudo" I get asked for the password. I enter it and get to run programs in the /sbin directory. However, if I enter "su -" I get asked for the password, but it comes back as unrecognised for some reason. Give me Puppy or Slax or PClinuxOS for maintenance purposes any day. Quality distros they are.

Well I reproduce below, for your delectation, the info you requested. I got different error messages this time before giving it up as too much of a PITA but maybe you can make some sense out of it. I got out my Puppy live CD and imaged the drive with no trouble at all, btw.
The image file is located in partition sdc6 and the target drive is sdb. Have fun.

dora@dora:~$ mount
/dev/sda1 on / type ext3 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
none on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
none on /dev type devtmpfs (rw,mode=0755)
none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
none on /dev/shm type tmpfs (rw,nosuid,nodev)
none on /var/run type tmpfs (rw,nosuid,mode=0755)
none on /var/lock type tmpfs (rw,noexec,nosuid,nodev)
none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
gvfs-fuse-daemon on /home/dora/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=dora)
/dev/sdb2 on /media/b7b5ddff-ddb4-48dd-84d2-dd47bf00564a type ext4 (rw,nosuid,nodev,uhelper=udisks)
/dev/sdc6 on /media/19c11fff-5fb4-4b7c-b912-c106d5e81bd0 type ext3 (rw,nosuid,nodev,uhelper=udisks)
/dev/sdc7 on /media/160496d6-3e48-430e-8b04-9880e08a951a type ext3 (rw,nosuid,nodev,uhelper=udisks)
/dev/sdc9 on /media/b9c8dd65-9964-479b-a7e6-593680c72c66 type ext3 (rw,nosuid,nodev,uhelper=udisks)
/dev/sdc5 on /media/6f1733ba-2375-4000-939e-a19a0020bf88 type ext2 (rw,nosuid,nodev,uhelper=udisks)
/dev/sdb1 on /media/3312-932F type vfat (rw,nosuid,nodev,uhelper=udisks,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,flush)
/dev/sdc8 on /media/77C23020075F9410 type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096,default_permissions)
dora@dora:~$ ls /media/19c11fff-5fb4-4b7c-b912-c106d5e81bd0/
lost+found raspberrypi_timer_sdcard.image.gz
pi_raspbian_timelock_entire_image_latest.gz
dora@dora:~$ su-
No command 'su-' found, did you mean:
Command 'sup' from package 'sup' (universe)
Command 'sux' from package 'sux' (universe)
Command 'sum' from package 'coreutils' (main)
Command 'su' from package 'login' (main)
su-: command not found
dora@dora:~$ su -
Password:
su: Authentication failure
dora@dora:~$ su -
Password:
su: Authentication failure
dora@dora:~$ su -
Password:
su: Authentication failure
dora@dora:~$ sudo umount /dev/sdc6
[sudo] password for dora:
dora@dora:~$ sudo umount /dev/sdb1
dora@dora:~$ sudo umount /dev/sdb2
dora@dora:~$ mount
/dev/sda1 on / type ext3 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
none on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
none on /dev type devtmpfs (rw,mode=0755)
none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
none on /dev/shm type tmpfs (rw,nosuid,nodev)
none on /var/run type tmpfs (rw,nosuid,mode=0755)
none on /var/lock type tmpfs (rw,noexec,nosuid,nodev)
none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
gvfs-fuse-daemon on /home/dora/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=dora)
/dev/sdc7 on /media/160496d6-3e48-430e-8b04-9880e08a951a type ext3 (rw,nosuid,nodev,uhelper=udisks)
/dev/sdc9 on /media/b9c8dd65-9964-479b-a7e6-593680c72c66 type ext3 (rw,nosuid,nodev,uhelper=udisks)
/dev/sdc5 on /media/6f1733ba-2375-4000-939e-a19a0020bf88 type ext2 (rw,nosuid,nodev,uhelper=udisks)
/dev/sdc8 on /media/77C23020075F9410 type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096,default_permissions)
dora@dora:~$ sudo gunzip -c /dev/sdc6/pi_raspbian_timelock_entire_image_latest.gz | dd of=/dev/sdb conv=sync,noerror bs=4096
dd: opening `/dev/sdb': Permission denied
gzip: /dev/sdc6/pi_raspbian_timelock_entire_image_latest.gz: Not a directory
dora@dora:~$ sudo chown -R dora:dora /dev/sdb
dora@dora:~$ sudo gunzip -c /dev/sdc6/pi_raspbian_timelock_entire_image_latest.gz | dd of=/dev/sdb conv=sync,noerror bs=4096
gzip: /dev/sdc6/pi_raspbian_timelock_entire_image_latest.gz: Not a directory
0+0 records in
0+0 records out
0 bytes (0 B) copied, 0.0274383 s, 0.0 kB/s
dora@dora:~$ sudo mkdir /media/disk1
dora@dora:~$ sudo mount /dev/sdc6 media/disk1
mount: mount point media/disk1 does not exist
dora@dora:~$ ls /media
160496d6-3e48-430e-8b04-9880e08a951a b9c8dd65-9964-479b-a7e6-593680c72c66
19c11fff-5fb4-4b7c-b912-c106d5e81bd0 disk1
6f1733ba-2375-4000-939e-a19a0020bf88 diskk
77C23020075F9410

Did you chown the /dev/??? You may not get the permissions running chown /media/???? rather you should run chown /dev/??? to get permissions over the device vs. the dir the device is mounted in. I run as root as well, and use dd regularly. You may also have to change the permissions vs just the owner as well.

I hate to be Mr Negative but if you're having problems in Ubuntu (or any other distro) due to not being able to log in as root then you've not learned as much as you ought to. I'm not a fan of the Ubuntu "sudo always" approach at all but it is fairly easy to work with or work around you just have to read more and take time to learn.

No idea what you mean. I MUCH PREFER having separate root and user accounts protected by different passwords. I only installed Ubuntu on this netbook because when you're travelling it's got everything you need straight out of the box. But it only asked me to enter one single password when I installed it which I wasn't happy about from day 1. But like I say, when you're in other countries there are more important criteria to worry about.

You can enable the root account in Ubuntu and its forks if you want and it's not difficult.

Yes, I could but I won't. I regard Ubuntu as the Windows of the Linux world and as such it has its place, and it's a useful place as far as it goes, but certainly not for doing root level maintenance jobs IMHO.