unable to write to hdd

[lemon]

Hi,

I'm currently using 11.10 on eeePC 1215b with 500GB hdd. HDD is divided into 3 primary partiotions: 40GB ext4 (main kubuntu drive), 60GB FAT32 (unused atm), 40GB ext4 (unused atm) and 1 extended partition which contains 80GB /home folder and rest are 2x 130 GB (first is ext4 and second is fat32). For about 2 weeks I'm having problems with either writing to USB stick (ocz rally 2 16GB fat32) or to partitions created during installation process. USB stick was tested with h2wtest tool on windows with no errors (testing is performed by writing 1GB files to USB stick and checking their integrity). HDD wasn't yet tested although i assume no major problems with it since problems started during day-2-day basis (power off -> work -> power on). I searched for similar problems posted somewhere and found info from last year that some security update managed to do that, but those posts were about 6 months old and no new ones are created - this leads me here where maybe someone can guide me through the fixing process. BTW, system is week old, no weird repository entries, no weird drivers except fglrx.

Thanks in advance for any help.

edit: using USB stick on other machine with win7 without problems...

[james147]

For about 2 weeks I'm having problems with either writing to USB stick (ocz rally 2 16GB fat32) or to partitions created during installation process.

How are the partitions mounted? This sounds like a permissions problem rather then a problem with the drives so can you write to the partitions as root?

during day-2-day basis (power off -> work -> power on)

Interesting work flow

[lemon]

How are the partitions mounted? This sounds like a permissions problem rather then a problem with the drives so can you write to the partitions as root?

sudo cp works ok on all mentioned partitions including USB drive. before problems started mount was done right after system start and all the drives where ready to use (/media had them all listed so i assume this means they were added correctly to fstab file), right now it looks like it is the same, however fstab file looks like this:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc nodev,noexec,nosuid 0 0
# / was on /dev/sda1 during installation
UUID=0a9abd58-77a4-47bf-8b34-47435a2ff047 / ext4 errors=remount-ro 0 1
# /home was on /dev/sda5 during installation
UUID=5cc43de3-bbc2-4c9d-911f-4828871ab890 /home ext4 defaults 0 2

please notice weird labels of devices...is this normal? i mean i didn't add any during partitioning but i was under the impression adding labels to linux used partitions was pointless (i mean i have separate partition for /home and never have thought i should name it...). is changing those labels possible? after lunching kde partitioning tool, all fields are greyed despite kde asking me for root pwd...

Interesting work flow

hehe, i meant myself: surfing while morning press on laptop, then powering it down, going to work and powering it up to do some other stuff

[james147]

sudo cp works ok on all mentioned partitions including USB drive

That confirms it being a permission problem.

/media had them all listed so i assume this means they were added correctly to fstab file

/etc/fstab is not the only way to mount devices, it is generally used for devices that should always be mounted at boot. These days other devices are mounted on the fly with udev.

UUID=0a9abd58-77a4-47bf-8b34-47435a2ff047 / ext4 errors=remount-ro 0 1
UUID=5cc43de3-bbc2-4c9d-911f-4828871ab890 /home ext4 defaults 0 2

This suggest that udev is probably mounting the other devices.

please notice weird labels of devices...is this normal?

UUID's are not labels, its a unique id for the filesystem (generated when creating the filesystem without your intervention). This is used to stop the system failing to boot if the disk layout changes (ie, if /dev/sda becomes /dev/sdb)

under the impression adding labels to linux used partitions was pointless

Not pointless, just another way to refer to the device. There are three ways you can refer to the device is linux, the device file (ie /dev/sda) or the UUID (as above) or by label (you could replace UUID=xxx with LABEL=xxx). UUID is the least ambiguous (it should never change after formatting and should never conflict with another device) which is why ubuntu uses it as the default.

is changing those labels possible? after lunching kde partitioning tool, all fields are greyed despite kde asking me for root pwd...

It is possible with "e2label <device> label" (or similar command for non ext filesystems)

The kde partitioning tool is probably greying out the options as you should modify the partition while it is mounted.

As for an actual fix, you can chmod or chown the directories you want to write to (and I think you need to do this for ext) or configure udev to mount them with the proper permissions (probably the better option for vfat)... though I am not sure why its not doing this by default (which it should do if kde is causing them to be mounted).

You can run the "mount" command (without arguments) to see what is mounted with what options vfat volumes should have a umask set for them to be writeable for normal users.

[lemon]

thanks for quick anwsers below mount output:


/dev/sda1 on / type ext4 (rw,errors=remount-ro,commit=0)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
/dev/sda5 on /home type ext4 (rw,commit=0)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
/dev/sda6 on /media/05382504-7cfe-4778-8089-baff90ed6ab0 type ext4 (rw,nosuid,nodev,uhelper=udisks)
/dev/sda7 on /media/50de5628-fa8a-48da-8f46-03ea43881244 type ext4 (rw,nosuid,nodev,uhelper=udisks)
/dev/sda2 on /media/8D26-907A type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed ,dmask=0077,utf8=1,showexec,uhelper=udisks)
/dev/sda3 on /media/4eba7c62-46f4-4f8a-a7ec-1c2b4cff65d4 type ext4 (rw,nosuid,nodev,uhelper=udisks)
/dev/sdb1 on /media/2E42-08A4 type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed ,dmask=0077,utf8=1,showexec,uhelper=udisks)

last line represents USB drive, on rest, rw label is present (so read write should be possible right?). i also looked up for some info regarding udev command and made decision not to play with it until i get more familiar with linux anyway, is it possible that this is solely related to some sw problem? i mean during update or something (after fresh install, couple of security updates including kernel upgrade were performed...)

thanks a lot for quick responses

[james147]

/dev/sdb1 on /media/2E42-08A4 type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed ,dmask=0077,utf8=1,showexec,uhelper=udisks)

uid and gid are set and pointing to the first user (with id 1000), are you the only user on the system? You can confirm who has the uid 1000 with

cat /etc/passwd | grep 1000

if that is you then what is the output of

ls -l /media
ls -l /media/*

if its not you then can that user write to the directories?

[lemon]

mornin',

output of above commands
piotrek@1215B:~$ cat /etc/passwd | grep 1000
piotrek:1000:1000iotrek,,,:/home/piotrek:/bin/bash
piotrek@1215B:~$ ls -l /media/
total 52
drwxr-xr-x 3 root root 4096 2012-01-26 20:16 05382504-7cfe-4778-8089-baff90ed6ab0
drwx------ 9 piotrek piotrek 8192 1970-01-01 01:00 2E42-08A4
drwxr-xr-x 3 root root 4096 2012-01-26 20:16 4eba7c62-46f4-4f8a-a7ec-1c2b4cff65d4
drwxr-xr-x 3 root root 4096 2012-01-26 20:11 50de5628-fa8a-48da-8f46-03ea43881244
drwx------ 2 piotrek piotrek 32768 1970-01-01 01:00 8D26-907A

and yes, i'm the only user i'm sorry but i'm not familiar with above description: all i know is that d stands for directory, r for read and w for write, however why there are 3 "columns" with such rights? safe to say would be that changing rights to those folders for 777 would give me full access, but is it recommended? thanks james

[james147]

drwxr-xr-x 3 root root 4096 2012-01-26 20:16 05382504-7cfe-4778-8089-baff90ed6ab0

You are right, d is for directory, and r is for read, w for write and x for executable (not directories need to be executable to be able to read them)
rwxr-xr-x is slpit into three groups: owner, group, other so for this it means the owner has full access, the group has read and exec and everyone else has read an exec
I think the 3 is the number of hard links to the directory (subfolders tend to link to their parent, thats why this is 3 and not 1)
root root means it is owned by root and belongs to the root group.
4096 is the size (directories are always 4k)
then comes the date
and lastly the name (note that if you give the filesystem a label then udev will use that as the mount point name instead of the UUID)

safe to say would be that changing rights to those folders for 777 would give me full access, but is it recommended?

That is right, and not recomemded... 777 will make all files executable which is probably not desired.

better solutions would be to chown the directory (and possibly sub directories as well) to your user, since you are the only user. Or should you want multiple users to access it then change the group, add the users you want to have accesss to that group and "chmod -R g+rw <path>" it to give that group read access. However, if you want everyone to access it and you care less about security then "chmod -R a+rwX <path>" is a better command to use (it means add to all permissions read write and to directories write, the lowercase x adds exec to directories and files and the -R makes it recursive).

Although since they already have read and exec it should be enough to "chmod -R a+w <path>".