Posts by villeneuve

    EDIT: I've now managed to work around my issue so I don't need help anymore. However I think OMV should offer a setting in the webinterface to disable the quota stuff with on click. While at it I also came across the fact that user ids below 1000 are not shown in the webinterface which is very annoying & I wonder what lead to that decision if it's not a bug. Cheers!

    Hello, I have trouble with those aquota-files, too, and want to get rid of them but ran into the same issue. Here's what I get:

    root@Videostore-OMV:/media# stat /media/57d1724e-cb0f-4fab-abde-95982ca5117d/
    Datei: „/media/57d1724e-cb0f-4fab-abde-95982ca5117d/“
    Größe: 7168 Blöcke: 16 EA Block: 4096 reguläre Datei
    Gerät: 801h/2049d Inode: 12 Verknüpfungen: 1
    Zugriff: (0600/-rw-------) Uid: ( 0/ root) Gid: ( 100/ users)
    Zugriff : 2020-01-08 21:34:12.722186933 +0100
    Modifiziert: 2017-10-23 01:25:51.694281520 +0200
    Geändert : 2017-10-23 01:25:51.694281520 +0200
    Geburt : -

    What can I do?

    The file is saved in that directory where you were when you started nano unless you specified a directory when starting nano.
    So for example launching nano with

    nano /tmp/test.txt

    would put that text-file into the "/tmp"-directory.
    Beware that /tmp usually gets deleted on shutdown/reboots of the system.

    After trying a lot of things I did a clean install to the new USB drive. After the first boot, which went fine, I was busy with other stuff, so the system just sat idle. When I came back tty1 showed the following:

    EXT4-fs error (device sdc1): ext4_mb_generate_buddy:758: group 3, block bitmap and bg descriptor inconsistent: 18977 vs 184 free clusters
    Aborting journal on device sdc1-8.
    EXT4-fs (sdc1): Remounting filesystem read-only
    EXT4-fs error (device sdc1): ext4_journal_check_start:56: Detected aborted journal

    I'm out of ideas now and will try another USB-stick tomorrow.

    I recently cloned my OMV-installation onto another USB-stick. To do that I bootet into a live-cd and used the command if=/dev/sdx of=/dev/sdy bs=4K . It all went fine and worked for weeks.

    Yesterday though the system would not boot anymore. It gave me the following error:
    error: file '/boot/grub/i386-pc/normal.mod' not found.
    Entering rescue mode...

    When I tried to fix the problem using a Linux live-cd I discovered that the file system on the USB-stick was damaged and I could not repair it with fsck either.
    I then went for the easiest solution and cloned the old USB-stick again onto the new one. OMV then bootet again.

    I then decided to update it but could not do it since it told me that "/var/cache/apt/archives/partial" was read only. I already assumed that I'm back into trouble and wondered if the root-filesystem is damaged again. To find out I initiated a reboot and sure enough I received the "error: file '/boot/grub/i386-pc/normal.mod' not found."-error again.

    Before all this I had tested the new USB-stick with H2testw for errors, but it looked all good.

    Does anyone have any clue what's going on?

    Thanks for reading!

    *EDIT* I once again checked the USB-stick with H2testw and it tested it successfully.

    Ok, I just had the impression that while you were agreeing about 2 GB being not enough you saw no need to change the official minimum/recommendation.
    I'd say 4GB should be listed as being the minimum for bare nacked installations and 8 GB for installation with additional software.
    So how can we reach Volker to change the wiki or is it likely that he will read this thread in the near future anyway?

    Why not do anything important with it? The userdata is on other drives anyway, so that's save and the stick can be imaged easily.
    The 2 GBs for me filled up on every release update and sometimes even when smaller updates were done.
    I used other projects like FreeNAS for years before moving to OMV and in the beginning those projects were kind of advertising "hey, use old hardware you have sitting around and create a NAS out of it", so that's where at least my approach came from initially.
    Just because Microsoft and a lot of other, mostly commercial software providers make the mistake of giving too low minimum requirements OMV doesn't need to do the same and you posting again and again and again here in the forum is pretty meaningless when the wiki says 2 GB.
    This discussion is pointless anyway, since my initial posting was only about changing the wiki entry. Please do it!

    I don't know if you can still buy 2 GB sticks, but for sure a lot of people might read the system requirement saying 2 GB (https://wiki.openmediavault.or…x.php?title=Prerequisites) and will take such a stick out of their drawer. That's what I did because I like using stuff that's perfectly ok and otherwise would just collect dust and it worked very well at first, but that was with an older version of OMV. Yes, my sticks were all H2testw tested successfully BTW.
    My OMV (a pure backup system, so nearly no extra plugins/services installed) that was installed on a 4 GB stick from the beginning runs trouble free, so I suggest to change the requirement listed in the wiki to 4 GB and maybe add a recommendation that for installing many plugins and services an 8 GB stick would be better.
    I also like the idea of recommending testing the flash memory beforehand.
    After my bad experience with 2 GB sticks I now cloned all my OMV-installations to 4 GB or bigger sticks using dd so I'm good to go.

    after having trouble related to a full system drive time and time again with those OMV-machines I run from 2 GB USB-sticks I propose to change the system requirements mentioned on from 2 GB to 4 GB for the system drive.
    I think that could save many beginners a lot of time and frustration.
    What do you guys think?

    I have the same problem and as a workaround I placed a txt-file named after the partition into every partition's top directory. So you also know when you're on the pool partition because there you'll see multiple of the txt-files.

    I'm running OMV 2.2.13 with kernel 3.16.0-0.bpo.4-amd64 on a 2 GB USB-stick in combination with the flashmemory-plugin.
    Since I've setup the system recently with empty harddiscs a lot of user-data was copied to the system the last days.
    I've now run got the message that the rootfs is full. I searched the forum and tried the suggestions, but my problem seems to differ.
    I found out that /var/log/debug and /varlog/system must be the files filling up the rootfs as they are 180 MB and 284 MB in size respectively.
    I looked into them and despite having kept the default "Log level" setting of the SMB/CIFS service I find A LOT of entries in the "sytem" and "debug" files.
    sda1 and sda2 are my harddrives for user-data, sdc is the system drive where OMV is installed on.
    This is a excerpt:

    How do I prevent this?

    Thanks for reading!

    Yes, I have set "Check interval" to the default 1800 and "Power Mode" to "Standby", but I have not scheduled tests.
    However there is a problem with the Seagate Archive disks that often results in hdparm -C /dev/sdx giving the result "drive state is: unknown". Maybe that is the cause for my problem, so that smartmontools wakes up the drive regardless of what is set as "Power Mode". The output of hdparm -C /dev/sdx is the same on both drives, but the frequent spin-ups seem to only happen on sda, which makes me wonder about a firmware-problem, because sda runs AR13 firmware and sdb is equipped with AR15. Seagate seem to offer updates to AR17 now, so I'll try to get it for both drives and see if the problem persists. Thanks!

    The output is:

    [79302.183422] smbd(31521): dirtied inode 141885503 (index) on sdb1
    [79302.324836] smbd(31521): dirtied inode 141885504 (info) on sdb1
    [79302.335551] smbd(31521): dirtied inode 141885505 (marks) on sdb1
    [79302.344334] smbd(31521): dirtied inode 141885506 (resume) on sdb1

    sda is the drive I'm investigating why it's waking up. sda and sdb are both 8 TB Seagate Archive HDDs, sdc is the drive OMV is installed on and that is a USB-stick.

    I tested your script, which is a great idea, as I have disks waking up for no apparent reason, but the only thing it says when the disk spins up is "Drive is awake"! There are no further messages. Could it be that the script doesn't work on a system also running the flashmemory-plugin?

    Just make a full backup image of your system drive to be able to go back to your OMV 2.0 configuration.
    I tried to do the upgrade just out of curiosity and it failed because of a lack of space on the 2 GB USB stick the system was running on.