Loosing permissions overnight

summary:

Revoered 1TB book (single disk) is now loosing write permissions - no hacks currenty in place.

Loosing permissions overnight

B3ast 1207742955|%e %b %Y, %H:%M %Z|agohover

Hi,

After playing with SSH and a few other hacks I have reverted back to the standard config using the recsue procedure. All seemed well yesterday and I set serveral files copying over however at around midnight I lost permission to write to the share.

The share was created using the web gui and I gave everyone full permissions. I have tried re-applying the permissions but its still not working. Short of hacking in SSH again is there any way of fixing this? Also is there any reason for it breaking in the first place? I have tried mapping drives using the root account and another account (with full perms) with no luck.

Ta B3ast

Re: Loosing permissions overnight

zx3junglist 1207750467|%e %b %Y, %H:%M %Z|agohover

do 'ls -al' on the shares/internal folder and report it back here, we need to see what the perms are and who the folders belong to

you should see that the folders belong to www-data, make sure this is the case, use chown if not

last edited on 1207750497|%e %b %Y, %H:%M %Z|agohover by zx3junglist + show more

Re: Loosing permissions overnight

B3ast 1207754788|%e %b %Y, %H:%M %Z|agohover

Ok have logged in ussing ssh and here are my folders

total 24
drwxr-xr-x 4 root root 4096 Mar 26 2007 .
drwxr-xr-x 21 root root 4096 Apr 9 10:34 ..
drwxr-xr-x 2 root root 4096 Mar 26 2007 external
drwxr-xr-x 6 root root 4096 Apr 8 21:50 internal

total 40
drwxr-xr-x 6 root root 4096 Apr 8 21:50 .
drwxr-xr-x 4 root root 4096 Mar 26 2007 ..
drwx-- 2 root root 4096 Apr 8 21:30 .senvidData
drwx-- 2 www-data root 4096 Apr 9 03:16 MOVIES
drwxrwxr-x 2 root www-data 4096 Apr 8 21:30 PUBLIC
drwx-- 2 root root 16384 Apr 9 02:12 lost+found

Re: Loosing permissions overnight

B3ast 1207812197|%e %b %Y, %H:%M %Z|agohover

Ok I added in www-data onto MOVIES using chown however after rebooting the box the permissions have been lost again. I could keep logging in and updating them but would rather get a more permanent fix any ideas?

Re: Losing permissions overnight

andyh-rayleigh 1207896155|%e %b %Y, %H:%M %Z|agohover

I have been having this sort of problem even before any sort of hacking the unit.
Generally happens part way through a large series of copies to the filesystem.

On setting up telnetd and investigating I find that the initial mount stage:

[root@MyBookWorld /]# mount
/dev/root on / type ext3 (rw,noatime,data=ordered)
proc on /proc type proc (rw)
devpts on /dev/pts type devpts (rw)
sys on /sys type sysfs (rw)
/dev/md3 on /var type ext3 (rw,noatime,data=ordered)
/dev/md4 on /shares/internal type ext3 (rw,noatime,data=ordered)
usbfs on /proc/bus/usb type usbfs (rw)

changes to /shares/internal being "ro" for no apparent reason.
(I've also observed this for /var, but this (obviously) doesn't lead to quite the same problem)

any idea why this happens … and what I can do about it?

Andy

Re: Losing permissions overnight

alephsmith 1207896713|%e %b %Y, %H:%M %Z|agohover

If your disk is damaged, it can often kick you in to ro mode to save your data. There was a post about it here previously I think, try the search.
You may need to send your HDD back to WD for a replacement.

Re: Losing permissions overnight

andyh-rayleigh 1208114808|%e %b %Y, %H:%M %Z|agohover

Problem is also occurring with a second MyBook World so it seems like physical hardware problems would be too much of a coincidence.
This time I've managed to find something fairly clear in the messages log:

Apr 13 18:25:40 MyBookWorld user.alert kernel: journal_bmap: journal block not found at offset 3084 on md4
Apr 13 18:25:40 MyBookWorld user.err kernel: Aborting journal on device md4.
Apr 13 18:25:40 MyBookWorld user.crit kernel: ext3_abort called.
Apr 13 18:25:40 MyBookWorld user.crit kernel: EXT3-fs error (device md4): ext3_journal_start_sb: Detected abo rted journal
Apr 13 18:25:40 MyBookWorld user.crit kernel: Remounting filesystem read-only
Apr 13 18:25:40 MyBookWorld user.warn kernel: __journal_remove_journal_head: freeing b_frozen_data
Apr 13 18:29:18 MyBookWorld user.warn kernel: __journal_remove_journal_head: freeing b_committed_data
Apr 13 18:29:19 MyBookWorld user.notice block.agent[1515]: USB umount event not supported
Apr 13 18:48:28 MyBookWorld user.info kernel: kjournald starting. Commit interval 5 seconds
Apr 13 18:48:28 MyBookWorld user.warn kernel: EXT3-fs warning: mounting fs with errors, running e2fsck is rec ommended

(of course fsck isn't possible, still. System obviously could do with a larger swap partition.)

I'm running a reformat with full write check on the md4 partition - it hasn't yet found any write
errors in the past 2 hours … at present rate it'll be another day before it completes.
A full read check (dd if=/dev/md4 of=/dev/nul) completed with no errors.

Looks like a software problem, possibly a race condition.

Andy

Re: Losing permissions overnight

andyh-rayleigh 1208238755|%e %b %Y, %H:%M %Z|agohover

Don't try the full write check version of format … on the 1tb it takes ~36 hours for the first data pattern then starts another :-(

Anyhow, no write errors found on the partition to match the no read errors previously.

Andy

Re: Losing permissions overnight

B3ast 1207907785|%e %b %Y, %H:%M %Z|agohover

I only got my Ibook on last weekend and yes it was also doing it before any hack's (which is when i found this site and started trying SSH). The disk itself works fine when the permissions are right. Maybe I should try using it from my XP box and see how that goes - at the moment I use is mainly on Vista…

Re: Losing permissions overnight

alephsmith 1207913089|%e %b %Y, %H:%M %Z|agohover

Have you checked to see that your logged in as a privileged user. i.e. when you access the smb share from your file manager what user are you logging in as?

I know that from my OS X machine, it will default to the unprivileged guest account unless I specify alternate auth details. When this happens I lose write access to the share.

Re: Losing permissions overnight

blight 1207916800|%e %b %Y, %H:%M %Z|agohover

have a look here here. That was my problem with a brand one.

blight

Re: Loosing permissions overnight

andyh-rayleigh 1208355065|%e %b %Y, %H:%M %Z|agohover

After reformatting the md4 partition (and doing a bit of tuning on its parameters) the box now seems to be behaving much better.
I think the original formatting of the 1TB drives may not have properly set up the journal for the ext3 filesystem.
The main fear now is that the partition is too big for fsck on the box and so if (when!) something does go wrong I'll have to
temporarily stick the drive on a PC. It might have been better to split into two partitions, but I was worrid that there might have been other side effects.

Anyhow, looks better now.

Andy

Re: Loosing permissions overnight

Paddymagic 1208032984|%e %b %Y, %H:%M %Z|agohover

I have the same problem with my brand new MyBook 1TB.

After transferring about 2000-7000 files over the network or untaring over ssh the drive locks up and goes into read only mode. After a reboot /dev/md4 fails to mount, so I run fsck on it. 3 cups of tea later it finally finishes and after another reboot I can begin writing again… until the drive locks up again. I've repeated this about 3 times today and have only managed to get 10000 of my many tiny files onto the drive.

I havent tried copying over a large file yet to see just what happens, I'm not sure if there could be any issues with copying 20000+ files to a single directory or if its simply the drive which is faulty.

Has anyone found a working solution and would they like to share it?

Re: Loosing permissions overnight

Gabriel74 1208203648|%e %b %Y, %H:%M %Z|agohover

I have same problem, but nobody help me until yet…

Re: Loosing permissions overnight

B3ast 1208372470|%e %b %Y, %H:%M %Z|agohover

I have finally made some progress on this - it looks like that at some points during my writing to the disk the mount becomes read only

/dev/root on / type ext3 (rw,noatime,data=ordered)
proc on /proc type proc (rw)
devpts on /dev/pts type devpts (rw)
sys on /sys type sysfs (rw)
/dev/md3 on /var type ext3 (rw,noatime,data=ordered)
/dev/sda4 on /shares/internal type ext3 (ro,noatime,data=ordered)
usbfs on /proc/bus/usb type usbfs (rw)

I ran these commands to get it back into read write mode gave it a reboot and its working again

umount /dev/sda4

mount /dev/sda4 /shares/internal -t ext3 -o rw data=ordered

mount

/dev/root on / type ext3 (rw,noatime,data=ordered)
proc on /proc type proc (rw)
devpts on /dev/pts type devpts (rw)
sys on /sys type sysfs (rw)
/dev/md3 on /var type ext3 (rw,noatime,data=ordered)
usbfs on /proc/bus/usb type usbfs (rw)
/dev/sda4 on /shares/internal type ext3 (rw,noatime,data=ordered)
[root@MyBookWorld /]#

Will see how long it lasts before going again……

Edit - lasted about 5 mins before going read only again :-( I copied about 1gb onto it…..

/dev/sda4 on /shares/internal type ext3 (ro,noatime,data=ordered)

last edited on 1208374323|%e %b %Y, %H:%M %Z|agohover by B3ast + show more

Re: Loosing permissions overnight

DreaMr 1212176829|%e %b %Y, %H:%M %Z|agohover

Hi

Has anyone found a solution to this yet, one that doesn't involve reformatting?

I used to had trouble with transfering files at first, and I found out that formatting helps. It did do the job, and all was fine for little while, but now the permissions get lost about every 24 hours or so again, though not because of filetransfers now. I really wouldn't like to reformat again, because it would be pretty troublesome to get all the stuff I have in there back to somewhere else for the duration (hard drive space beign the issue here)… and if the problem comes again like it did now, it's not really worth it anyways. I get the following kernel messages too when the shares fail:

<1>journal_bmap: journal block not found at offset 1036 on md3
<3>Aborting journal on device md3.
<2>ext3_abort called.
<2>EXT3-fs error (device md3): ext3_journal_start_sb: Detected aborted journal
<2>Remounting filesystem read-only

Have to reboot mybook twice to get it working again. The first boot causes the drive to panic with flashing leds, second one gets it up again with some warning in kernel messages:

<4>EXT3-fs warning (device md3): ext3_clear_journal_err: Filesystem error recorded from previous mount: IO failure
<4>EXT3-fs warning (device md3): ext3_clear_journal_err: Marking fs in need of filesystem check.
<4>EXT3-fs warning: mounting fs with errors, running e2fsck is recommended
<6>EXT3 FS on md3, internal journal
<6>EXT3-fs: recovery complete.
<6>EXT3-fs: mounted filesystem with ordered data mode.

It's really a pain in the arse to do the double reboot once in a day, especially because it requires resetting from the power button. Otherwise a cron job could be a temporary fix.

My fstab
/dev/root / ext3 rw,noauto,noatime 0 1
proc /proc proc defaults 0 0
devpts /dev/pts devpts defaults,gid=5,mode=620 0 0
sys /sys sysfs defaults 0 0
/dev/md2 none swap defaults 0 0
/dev/md3 /var ext3 defaults,noatime 0 2
/dev/md4 /shares/internal ext3 defaults,noatime 0 2

Re: Loosing permissions overnight

gingerman 1225505015|%e %b %Y, %H:%M %Z|agohover

I have had these problems - losing the ability to copy to the device etc.

I reformatted the partition and recreated my directory structure etc. which stopped the device becoming Read Only so quickly.

It eventually became Read Only though and now takes less time to go back into that state. ( a few minutes )

I have to do a double reboot now like DreaMr

I get this when I # dmesg | tail

<6>Using fractional divider baud 115200, clock 100000000 dlf 40
<6>Using fractional divider baud 115200, clock 100000000 dlf 40
<1>journal_bmap: journal block not found at offset 2060 on md1
<3>Aborting journal on device md1.
<2>EXT3-fs error (device md1) in ext3_reserve_inode_write: Journal has aborted
<2>EXT3-fs error (device md1) in ext3_dirty_inode: Journal has aborted
<2>EXT3-fs error (device md1) in ext3_new_blocks: Journal has aborted
<2>ext3_abort called.
<2>EXT3-fs error (device md1): ext3_journal_start_sb: Detected aborted journal
<2>Remounting filesystem read-only

I have seen alot of different threads about the device going Read Only, and everyone seems to blame a different problem.

I think that it simply runs out of memory - something goes wrong and that's it Read Only ( but I am not a Unix expert )

I think I am going to kill most of the processes and see how long it lasts.

Re: Loosing permissions overnight

alephsmith 1225508369|%e %b %Y, %H:%M %Z|agohover

I'm not sure if you are asking this question or a different one but here it goes:

The reason that the device drops into ro mode is that it encounters a corrupt block in your hard drive. usually you would be prompted to run fsck to fix the problem. There are two problems with this a) fsck should not be run on a mounted partition b) the MBSW seems to run out of memory when running fsck anyway.

What we don't know is what is causing the corruption. I suspect that it is hardware related, I have never had the problem myself despite using the same firmware as everyone else.

I don't know if anyone has already, but it would be nice if someone could run fsck on a corrupt partition while connected to a linux box and see if that solves the error. This would certainly be easier than reformatting the whole drive.

Re: Loosing permissions overnight

Coronas 1225515642|%e %b %Y, %H:%M %Z|agohover

Why not add additional swap-memory and run fsck.ext3 manually?

dd if=/dev/zero of=/root/swapfile bs=1024 count=262144
mkswap /root/swapfile
swapon /root/swapfile
umount /shares/internal
fsck.ext3 -fy /dev/md4

That will take a couple of hours to run but in the end, it should work.
cu

last edited on 1225518443|%e %b %Y, %H:%M %Z|agohover by Coronas + show more

Re: Loosing permissions overnight

alephsmith 1225519990|%e %b %Y, %H:%M %Z|agohover

This guy is encountering corruption on md1. That is the root partition isn't it?

In addition to my last post, just rebooting isn't fixing the problem. The corrupt block is still sitting there waiting kick you into ro mode the next time your book tries to read from it.

Re: Loosing permissions overnight

Coronas 1225520889|%e %b %Y, %H:%M %Z|agohover

Right, overlooked that one. But adding swap is still an option for /dev/md3 or /dev/md4. For /dev/md1 I agree with you :)

Edit - has anybody set up a chroot environment on this box? This might work…
Edit2 - … or not. Probably just a stupid idea, it really is easier to check the drive in a linux box.

last edited on 1225523221|%e %b %Y, %H:%M %Z|agohover by Coronas + show more

Re: Loosing permissions overnight

gingerman 1225541104|%e %b %Y, %H:%M %Z|agohover

Update:
After killing Transmission torrent client, my device managed not to go into Read Only mode all night.

I have just restarted the daemon and am waiting for it to go down again. We shall see.

I will let you know if this has an effect.
If I go into RO mode, then I will do what Coronas said about swap files and work down the list - thanks for the suggestions - much appreciated.

Re: Loosing permissions overnight

gingerman 1225546839|%e %b %Y, %H:%M %Z|agohover

OK so Transmission seemed to help my device go RO with the help of me moving a large file at the same time, so I have initiated creating the swap file. I will keep you up to date with what happens.

last edited on 1225546877|%e %b %Y, %H:%M %Z|agohover by gingerman + show more

Re: Loosing permissions overnight

Coronas 1225553997|%e %b %Y, %H:%M %Z|agohover

@gingerman: my hints will only help you if you've got errors with the /var (/dev/md3) or /shares/internal (/dev/md4) partitons. But from your previous posts it's clear that it's your root-partiton / (/dev/md1) which has got some problems. You'll have better chances of fixing it if you hook the drive up to a linux-computer.

Re: Loosing permissions overnight

gingerman 1225561234|%e %b %Y, %H:%M %Z|agohover

Coronas, does this code make the swap file remain after a reboot?

dd if=/dev/zero of=/root/swapfile bs=1024 count=262144
mkswap /root/swapfile
swapon /root/swapfile
umount /shares/internal
fsck.ext3 -fy /dev/md4

Re: Loosing permissions overnight

Coronas 1225570603|%e %b %Y, %H:%M %Z|agohover

Yes. After creating the swapfile, all you have to do is to activate it with the swapon command, even after rebooting the device. But the file is located on the root partition of your drive - as long as this partition is errorfree, it's a healty setup. But if you want to check the root partition for errors, you have to unmount the partition. And this can't be done as long as the swap file is still active.