OMV4 system drive overflowed after a failed Snapraid sync

    • OMV 4.x

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • OMV4 system drive overflowed after a failed Snapraid sync

      Hi, and my system disk is completely full after I wanted to run a Snapraid Sync and got an error message "Probably the paerity file is missing".
      Unfortunately, I'm still a noob in terms of Linux, I would be glad if you could help me, as I get the system disk cleaned up again without having to reinstall everything again.

      The post was edited 1 time, last by SmallPity ().

    • First you need to find out, where the files have been synced to.

      What is the output of

      du -x -h -d1 /?

      This will show your the size of every folder in root (without descending on other filesystems)
      Odroid HC2 - armbian - Seagate ST4000DM004 - OMV4.x
      Asrock Q1900DC-ITX - 16GB - 2x Seagate ST3000VN000 - Intenso SSD 120GB - OMV4.x
      :!: Backup - Solutions to common problems - OMV setup videos - OMV4 Documentation - user guide :!:
    • macom wrote:




      What is the output of

      du -x -h -d1 /?

      This will show your the size of every folder in root (without descending on other filesystems)
      265M /opt
      4,0K /lib64
      14M /sbin
      84K /root
      130M /boot
      6,2G /var
      236G /srv
      4,0K /sharedfolders
      4,0K /home
      914M /usr
      953M /lib
      16K /lost+found
      4,0K /mnt
      13M /bin
      4,0K /export
      8,0K /media
      6,9M /etc
      244G /
    • Ok, /srv is quite big. /srv is where the other drives are mounte, but as we are not descending in other filesystems there must be something else.

      So let's see what there is:

      du -x -h -d1 /srv
      Odroid HC2 - armbian - Seagate ST4000DM004 - OMV4.x
      Asrock Q1900DC-ITX - 16GB - 2x Seagate ST3000VN000 - Intenso SSD 120GB - OMV4.x
      :!: Backup - Solutions to common problems - OMV setup videos - OMV4 Documentation - user guide :!:
    • macom wrote:

      Ok, /srv is quite big. /srv is where the other drives are mounte, but as we are not descending in other filesystems there must be something else.

      So let's see what there is:

      du -x -h -d1 /srv
      236G /srv/dev-disk-by-label-Paritaet1
      8,0K /srv/ftp
      236G /srv





      root@Server:~# df -h
      Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
      udev 3,8G 0 3,8G 0% /dev
      tmpfs 767M 9,0M 758M 2% /run
      /dev/sda1 244G 244G 0 100% /
      tmpfs 3,8G 4,0K 3,8G 1% /dev/shm
      tmpfs 5,0M 0 5,0M 0% /run/lock
      tmpfs 3,8G 0 3,8G 0% /sys/fs/cgroup
      tmpfs 3,8G 0 3,8G 0% /tmp
      1:2:3:4 15T 8,4T 6,0T 59% /srv/5385a6a9-eb65-44a8-a01c-d1230d3e3491
      /dev/sdc1 3,6T 2,1T 1,5T 59% /srv/dev-disk-by-label-Daten2
      /dev/sdb1 3,6T 2,1T 1,5T 59% /srv/dev-disk-by-label-Daten1
      /dev/sde1 3,6T 2,1T 1,5T 59% /srv/dev-disk-by-label-Daten4
      /dev/sdd1 3,6T 2,1T 1,5T 59% /srv/dev-disk-by-label-Daten3
    • root@Server:~# ls -l /srv
      insgesamt 28
      drwxr-xr-x 5 root root 4096 Sep 22 00:02 5385a6a9-eb65-44a8-a01c-d1230d3e3491
      drwxr-xr-x 5 root root 4096 Sep 22 00:02 dev-disk-by-label-Daten1
      drwxr-xr-x 5 root root 4096 Sep 22 00:02 dev-disk-by-label-Daten2
      drwxr-xr-x 4 root root 4096 Sep 22 00:02 dev-disk-by-label-Daten3
      drwxr-xr-x 4 root root 4096 Sep 22 00:02 dev-disk-by-label-Daten4
      drwx------ 2 root root 4096 Okt 12 12:29 dev-disk-by-label-Paritaet1
      drwxr-xr-x 2 ftp nogroup 4096 Aug 8 09:26 ftp
    • SmallPity wrote:

      drwx------ 2 root root 4096 Okt 12 12:29 dev-disk-by-label-Paritaet1
      That seems to be the issue, but I am not sure if it is safe to delete the directory. I am not using snapraid.

      Let's see if somebody else has an idea.
      @geaves
      @flmaxey
      Odroid HC2 - armbian - Seagate ST4000DM004 - OMV4.x
      Asrock Q1900DC-ITX - 16GB - 2x Seagate ST3000VN000 - Intenso SSD 120GB - OMV4.x
      :!: Backup - Solutions to common problems - OMV setup videos - OMV4 Documentation - user guide :!:
    • macom wrote:

      Let's see if somebody else has an idea.
      TBH I didn't answer because the request looked confusing and even after the above it still does. @flmaxey uses SnapRaid and I am in the process of moving to it using UnionFS.

      The confusing part here is the thread title, SnapRaid should have nothing to do with the drive OMV is installed on.

      But my understanding is this; say you have 4 drives you are going to use, 3 drives are for data and 1 which much be greater or the same size as the others. So if you have 4 x 2TB drives 3 are used for data and 1 is used for parity.

      I did however find this but I'm not sure if that will help....but the message "Probably the parity file is missing" could imply that this has not been set up correctly, but it could also mean that SnapRaid is confused because there are 2!!

      Another option would be to inspect the content of the parity by cd /srv/dev-disk-by-label-Paritaet1 then doing ls -l that will at least list the files on that drive.

      Perhaps another option might be to have the output of blkid.

      But going back to that link it could also mean to check the snapraid.conf and config file, but not sure what the later is.
      Raid is not a backup! Would you go skydiving without a parachute?
    • Hi, there are a total of 6 hard drives installed. Sda1 is system disk OMV. 4 more are data disks and 1 paerity hard disk. Snapraid was set up properly and ran for half a year without any problems. But then I wanted to sync again and there was an error message and suddenly the system disk was full
    • SmallPity wrote:

      Hi, there are a total of 6 hard drives installed. Sda1 is system disk OMV. 4 more are data disks and 1 paerity hard disk. Snapraid was set up properly and ran for half a year without any problems. But then I wanted to sync again and there was an error message and suddenly the system disk was full
      Ok so that's not the problem, looking at du -x -h -d1 /srv your output was;

      236G /srv/dev-disk-by-label-Paritaet1 this is wrong, wrong in the sense of the size and wrong in that it's a directory but I don't know why or how, unless there is some sort of corruption of the parity drive itself, hence the creation of that directory.
      8,0K /srv/ftp
      236G /srv

      This is the output from my own machine using the above;

      8.0K /srv/ftp
      12K /srv

      Something within the SnapRaid config has created that, but why and how? Have you looked at the file/s within that directory? cd /srv/dev-disk-by-label-Pariteat1 then ls -l.
      Raid is not a backup! Would you go skydiving without a parachute?
    • One possibility is that the SnapRAID parity drive didn't get mounted and when the sync was run, the parity file was newly created, but in the directory where the mount was supposed to happen. This could have caused the rootfs to fill up because /srv is on the rootfs.

      Look for a .parity file there - in the mount point directory with the parity drive not mounted.
      OMV 4.x - ASRock Rack C2550D4I - 16GB ECC - Silverstone DS380

      The post was edited 1 time, last by gderf ().