Posts by ceejayemm

    I have solved this problem myself.

    As noted above I do not use Disk Quotas and I confirmed this via the OVM File Systems page which showed all quotas as zero (ie not used). The server in question had a complete fresh installation when V5 was released and as far as I can remember I haven't played about with disk quotas since. To check out if Disk Quotas were indeed part of the problem I set the quota for the user account used to access these shares to 1TB and saved the settings. The Windows shares immediately showed the changed to being allocated 1TB of space and now had some free space too. I went back to the Disk Quota settings and changed then all back to zero and saved the settings. Now the shares in Windows showed the full array size as I wanted and had plenty of free space.

    As I note above I don't remember doing anything with the Disk Quota settings since the fresh V5 installation as its something I have never used before, nor should there have been anything carried forward from previous installs with a complete fresh installation. However resetting the disk quotas to zero has indeed solved the problem for me.


    I have two OMV v5.5.3 installations running on seperate servers, both provide CIFS/SMB file share services to my Windows 10 PCs. One of these servers seems to have a limit of 5GB per share despite having approx 2.5TB of free space of the disk array being used for the shared folders being shared via CIFS/SMB. Windows reports each share as full (at 5GB) when there seems to be ample free space available on the OMV server. The other server has 3 TB free space and the CIFS shares from that server report the full amount of free space available through Windows when accessing the share. I have no disk quotas enabled on either server.

    How can I remove the 5GB limit on the first server to make all the free space available to use in Windows ?

    Thanks for any help..


    I would agree with these sentiments. I too have used OMV for a long time, one of the things that appealled to me most was the existance of prebuilt and supported (by people who knew what they were doing - generally :) ) plugins. I don't use many but they helped me make a lot of progress in the early days. I started to look at OMV 5 in the early days of its release and waited for the plugin updates to come. When I enquired where they were I was hit with much the same answer as above - 'Use Docker' but with not a lot of advice as to how to do so.

    VotDev has put a lot of effort into the base build of OMV to make it easy to use (it simply is!) but the move to Docker for many of the plugins isn't. The introduction of Portainer, to help bridge the gap to full blown Docker (?), helps a bit and TechnoDadLive's excellent video tutorials also help but the majority of these are based on the Docker interface in OMV v4. I can see the merits of going the Docker route and the removal of problems with dependencies etc but the learning curve to make good use of Docker and its features is a big one. As the OP above says, its a move away from the original simplicity of OMV which still exists in the base product.

    I think I have worked my way through adding the 'plugins' i need via Docker but I haven't as yet had to upgrade one and I hope they are secure but without others to peer review them thats a bit of a scary unknown.

    So, on the whole, I would agree with the sentiments of OpenSourcePowered above but again 'this is only my opinion'

    I am setting up a new OMV virtual server on VirtualBox to test out Docker/Portainer on v5 prior to upgrading my existing OMV v4 servers to this version. I have dowloaded the OMV 5.0.5 ISO from SourceForge and created a basic OMV 5 installation. I then updated this to the latest OMV 5.3.7-1 (Usul) via the web app and also added the OMV Extras repo in readiness to installing Docker / Portainer. I added three 20GB virtual disks with the intention of creating a Raid5 array. These are each shown in the web app as /dev/disk/by-id/ata-VBOX-HARDDISK_<serialnumber> but show up in the RAID Mangement area as /dev/sdb, /dev/sdc and /dev/sdd ( and are similary listed by fdisk -l as well). When I try to create an new RAID5 array called 'Array1' I can check each of these disks to be included in the array but when I click Create I get the error:

    devices: The value '"\/dev\/sdb,\/dev\/sdc,\/dev\/sdd"' is not an array.

    The Full Details are shown as:

    Error #0:OMV\Json\SchemaValidationException: devices: The value '"\/dev\/sdb,\/dev\/sdc,\/dev\/sdd"' is not an array. in /usr/share/php/openmediavault/json/ trace:#0 /usr/share/php/openmediavault/json/ OMV\Json\Schema->validateArray('/dev/sdb,/dev/s...', Array, 'devices')#1 /usr/share/php/openmediavault/json/ OMV\Json\Schema->validateType('/dev/sdb,/dev/s...', Array, 'devices')#2 /usr/share/php/openmediavault/json/ OMV\Json\Schema->checkProperties(Object(stdClass), Array, '')#3 /usr/share/php/openmediavault/json/ OMV\Json\Schema->validateObject(Object(stdClass), Array, '')#4 /usr/share/php/openmediavault/json/ OMV\Json\Schema->validateType(Object(stdClass), Array, '')#5 /usr/share/php/openmediavault/rpc/ OMV\Json\Schema->validate(Object(stdClass))#6 /usr/share/php/openmediavault/rpc/ OMV\Rpc\ParamsValidator->validate('{"name":"Array1...')#7 /usr/share/openmediavault/engined/rpc/ OMV\Rpc\ServiceAbstract->validateMethodParams(Array, '')#8 [internal function]: Engined\Rpc\RaidMgmt->create(Array, Array)#9 /usr/share/php/openmediavault/rpc/ call_user_func_array(Array, Array)#10 /usr/share/php/openmediavault/rpc/ OMV\Rpc\ServiceAbstract->callMethod('create', Array, Array)#11 /usr/sbin/omv-engined(537): OMV\Rpc\Rpc::call('RaidMgmt', 'create', Array, Array, 1)#12 {main}

    I can create the array manually using:

    mdadm --create /dev/md0 --level5 --raid0devices=3 /dev/sdb /dev/sdc /dev/sdd

    but I would prefer to create it via the OMV app if possible.



    Great, but again links to these location in your reply would have meant I didn't need to reply again - saving you and me time and effort :-) Are there guides there which would help me understand how to:

    Install Docker ready for OMV
    Install OMV to a Docker installation
    Install 'other things' to a Docker installation already running OMV

    ie all the things somebody new to Docker (like me) would need to use it to replace (run alongside) my existing OMV installation. A 'sticky' post or a link to concise set of instructions for these items would be a good starting point for anybody looking to use a Docker/OMV installation for the first time.

    BTW - OMV (at least up to v4.x) majors in its documentation on its use of Plugins - is the use of Docker now changing this recommendation ? If so, this should be properly 'announced' somewhere.


    If it's now preferable (recommended ?) to use Docker instead of plugins then a 'How to..' or at least a link to help out poor souls like me who are old enough to think a Docker was somebody who unloaded ships :-) (Pre austerity of course!).

    This is just like the old days of early Unix/Linux when the uninitiated were told to edit a file (for example) by those 'who knew' without specifying the path to the file location. It would help those of us who 'don't know' if those 'who know' could be a bit more explicit in these sort of cases, then we can all benefit and not be subjected to this kind on implied scorn by those 'who know'.

    A moderator, especially, should know that a good first answer can reduce the number of subsequent tickets on the same or similar subject thus eventually actually reducing their workload.


    For some reason back in Sept 2018 I must have temporarily turned off my ClamAV processing and forgotten to turn it back on again. I upgraded today to 4.1.17-1 and in the process noticed that ClamAV was stopped so I turned it back on again only to get the following message in Syslog (also slight variation on screen):

    Jan 6 10:09:29 CMHomeNAS1 omv-engined[13421]: PHP Fatal error: Uncaught TypeError: Argument 1 passed to OMV\Config\ConfigObject::setAssoc() must be of the type array, string given, called in /usr/share/php/openmediavault/config/ on line 85 and defined in /usr/share/php/openmediavault/config/ trace:#012#0 /usr/share/php/openmediavault/config/ OMV\Config\ConfigObject->setAssoc('', false)#012#1 /usr/share/openmediavault/engined/rpc/ OMV\Config\Database->get('')#012#2 [internal function]: OMVRpcServiceClamAV->getOnAccessPathList(Array, Array)#012#3 /usr/share/php/openmediavault/rpc/ call_user_func_array(Array, Array)#012#4 /usr/share/php/openmediavault/rpc/ OMV\Rpc\ServiceAbstract->callMethod('getOnAccessPath...', Array, Array)#012#5 /usr/sbin/omv-engined(536): OMV\Rpc\Rpc::call('ClamAV', 'getOnAccessPath...', Array, Array, 1)#012#6 {main}#012 thrown in /usr/share/php/openmediavault/config/ on line 230

    Any help to resolve this issue would be much appreciated.


    My system:

    8GB RAM
    AMD A10-7700K 10 Core
    Linux 4.17.0-0.bpo.3-amd64
    5x2TB Data (SATA3)
    1x64GB SSD System (SATA3)

    I have 2 OMV servers, identical hardware and identically configured (both currently running OMV 3.0.96) to provide CIFS shares to my Windows 10 Desktop PC and Laptop. CMHOMENAS1 provides a music share, if I view the share properties (mounted on Windows 10 machines as drive W:) in Windows Explorer I can see that I have used 40GB and have Free Space of 3.16TB (correct). If however I look at the properties of my Backup share (provided by CMHOMENAS2) I see I have used 0.99TB and have 0 (zero) bytes free - strange. The OMV Storage / File Systems tell me that I have 3.58TB of which I have used 1.72TB (ie lots of free space on this RAID5 provided storage). The Backups CIFS share is the only share I have on this storage device. This is preventing me from running my Windows backups as the backup software thinks the backup location (via the Windows mapped drive) is full - not correct.

    Can anybody help me understand what I have done wrong in the set up of the Backups CIFS share on CMHOMENAS2 as I have checked and rechecked the settings so many times but cannot see where the problem lies.



    As a long time user of OVM, it seems that v2.x is the current stable version. However there are various postings that v3.0.x is 'stable enough (depending on the plugins in use') to regarded as 'stable'. On the OVM BugTracker site Votdev is now referencing updates to v3.1.x and on the News section of this site there are 'early views' of OVM v4.x. If this is confusing to me, how are new users to OVM supposed to know what is happening with this excellent project ? Isn't it time that there was a clearly visible statement as to what is 'officially' stable and thus identifies any other alpha or beta version that might be about - with any necessary warnings about their use. Clear links to each of the versions and their status should be available as part of the main setup of this site.



    Whilst I agree 2GB is pretty small it has served me well for the past couple of years, plus the fact that finding a replacement on Christmas Day would be be a little difficult! After recovering from the effects of yesterday I decided to blow away my existing OMV installation, which had been upgraded over time from 0.3.x to 1.7 up to yesterday. I took a copy of my setup (longhand, on paper), downloaded and burnt the base 1.0.20 .iso to DVD and, after disconnecting my raid array, reinstalled OMV to my existing DOM. This went OK and I upgraded the basic installation to 1.7 plus a couple of plugins. After checking out the new installation I closed the system down, reattached the RAID array and restarted my system. The RAID array was detected on start-up by OMV and once the system was backup again I have spent the last couple hours re-entering my config.

    The upshot of this is that I now have a new fully working OMV installation, running as 1.7 on the existing DOM with just under 1GB spare which should be OK until I can sort out a larger replacement for the system DOM. I would still like to know where all system disk space went to and a better means of recovering from such a event. During this time all the back-end processes (SSH,FTP, CIFS etc) were all working, it was just the front end web GUI which was unavailable to me. This seems odd as the back-end processes must be more take more resources than the GUI but yet it was the GUI which was unavailable with no real error message to say what was wrong. If it was the free space which was an issue then surely it should have been possible to put up some sort of error message to this effect rather than just 'nothing' in the form of a blank web page.

    I really like OMV and have used it for a long time, its a great system for beginners and more experienced users alike but something like this lets it down in my eyes. I am sure, with all the great developers and testers involved in this project, that this can be solved. Please don't take this as a criticism, just a plea for something to be done about this state of affairs.

    Thanks to all who suggested solutions, Happy Christmas and a happy New Year to you all.


    Thanks but I have already done that (and apt-get autoclean), removed old kernels, logfiles etc. I can't see any other 'trash' files and not sure what else I can remove. I have had a similar problem before and simply pruning the log files has sorted it out but not this time.

    Running out of ideas.



    You are right I am short of space on the system drive:

    Filesystem Size Used Avail Use%
    unted on
    rootfs 1.8G 1.6G 73M 96%
    udev 10M 0 10M 0%
    tmpfs 345M 868K 344M 1%
    /dev/disk/by-uuid/14540291-fe0e-4faf-8d07-f94b70686572 1.8G 1.6G 73M 96%
    tmpfs 5.0M 0 5.0M 0%
    tmpfs 715M 0 715M 0%
    tmpfs 1.7G 4.0K 1.7G 1%
    /dev/md127 3.6T 2.0T 1.5T 58%

    I normally have around 40% free but now only 4% free. How can I find out what has taken up this space ? I seem to remember a few weeks ago I had a problem with a hang whilst accessing files via Samba but other than that everything seemed to have been ok including this morning when running under 1.6 before the upgrade.

    BTW - the backend services (SSH, FTP, Samba) all seem to be working Ok



    After upgrading from OMV 1.6 to 1.7 all seemed OK, I logged out and a little while later when I went to login again (via hostname) I got the pale blue background for the login screen but no login dialogue box and no error. I have a fairly clean OMV installation with only the Autoshutdown, ClamAV and LVM plugins installed. I checked the system disk space and although its a bit low it should be enough for OMV to login (I know that little or no system disk space causes OMV a login problem - I wish there was a way to determine what causes the system disk to fill up and get it back to 'normal' but thats a seperate issue). I have tried logging in via Chrome and IE11 - both give the same result. If I connect via the IP number of server I do got a login dialogue box the first time I try but then nothing , the same as connecting to the hostname.

    I can't remember the exact details of my server but it has been used for OMV for the last 2 years without problems and is basically:

    AMD A3400 64 bit processor, 4GB memory, Intel NIC, 2GB DOM for system disk and 4 x 1TB disk in RAID 5 array for data storage.