[LibreElec 8.0.2] Media transfer stops halfway: "read-only file system"

  • I've just updated to LibreElec 8.0.2 from 8.0.0 today, and suddenly ran into this problem:

    I transfer my media files through Samba to my LE setup, and today, when I tried to transfer a 5Gb media file, it just stops at approx. 10%, and after a minute it gives me an 'Access denied' error. Trying to remove the file gives me the same error.

    I logged into LE with SSH, and tried to remove the broken file from there. This gives me the following response:

    rm: can't remove 'xxx': Read-only file system

    I never made this change myself, my media share should always be writable... I rebooted, once again logged in with SSH and was then able to remove the file.

    Once again, I tried to copy the same file the same way I did before - and again it stopped, a little sooner than before. Same problem: disk becomes read-only, until I reboot again.

    I've checked the logs, but there are no error reports whatsoever to be found in there.

    Is there something in LibreElec that can trigger this, as a safety measure of some sorts? Could this be that my media disk is 93% full (of 3TB) ?

    I copied a few smaller files just before this, and those went without a problem.

  • I have similar issues with LE 8.0.1, and suspected my hardware (dual hdd enclosure).

    Can you verify directly after an event with:

    Code
    mount

    and verify if the USB drive got a new 'device node' assigned (e.g. /dev/sdb1)?

    Also check the last lines in the output of:

    Code
    dmesg

    and look for hdd related messages.

    The drive that showed this behavior in my setup is an ext4 partitioned drive.

    (I'm not near my RPi, so cannot verify the messages I have seen.)

    Edit (2017-05-28): I only started to use this (dual) USB HDD after having 8.0.1.

    Edited once, last by RomMon (May 28, 2017 at 4:05 PM).

  • I've been backing up my media disk to prevent data loss in case the disk is faulty. Then I repeated the steps to try to reproduce the described problem. Somehow the transfer was able to complete without issues this time.

    In my case it's not an USB drive but internal SATA (Seagate Barracuda XT), and I know the device node hadn't changed after the event.

    If this problem occurs again, I'll check the dmesg output.

    Thanks for your input.