I have 0.4.35 OMV. I am serving linux based filesystems from a 2TB(formatted) RAID10 (underpinning LVM) made up of 4x1TB drives. Everything there works fine. (Indeed I find it quite impressive, speed wise, running on a repurposed D510)
I also have three flash based (SSD/SDHC) filesystems. Two of these are VFAT type filesystems, and as you know, linux permissions do not work correctly on VFAT filesystems. The best fix seems to be (Ref: https://www.kernel.org/doc/Doc…tion/filesystems/vfat.txt ) to set the UID and/or GID and/or UMASK of the filesystem at mount time. I have verified that this does indeed work. (By work here I mean that the desired user, which is a configured OMV user, can write to the share mounted via CIFS). The problem is that OMV creates the entry in /etc/fstab to look like this:
/dev/disk/by-uuid/C7E4-004C /media/C7E4-004C vfat defaults,nofail 0 2
and I need it to look like this:
/dev/disk/by-uuid/C7E4-004C /media/C7E4-004C vfat defaults,gid=100,umask=002,nofail 0 2
This would not be a problem if OMV would leave the entry alone once I get it the way I need it, however it appears that when my OMV box reboots that the filesystem mount entries are recreated.
This suggests to me that the best solution would be to alter the OMV UI and add an "Edit" function for vfat filesytems. This would then allow the user to optionally specify the UID, GID and MASK options for the mount entry in fstab. If nothing were specified, then the current "default" entry would be created.
A second alternative would be to alter the OMV code so that it did not alter vfat entries in /etc/fstab that contain any of these options.
There may be a third alternative that involves some durable configuration changes (that is, they survive a reboot) that can be done from the GUI or the command line that I am unaware of.
I welcome suggestions as to the third alternative (custom startup script that replaces fstab - probably *NOT* a good idea) or the likelihood of this being fixed in OMV code.
Note that when I say "OMV code" here I am lumping in the underlying kernel, drivers, etc with the ACTUAL omv code. I would welcome a fix at any of these points.