Beiträge von square_eyes

    I spent days troubleshooting a similar issue (single user working but no additional user). In spite of assertions this was to be fixed in the GU, I I found that the share blocking is hidden one level up: the mount point itself is 700, owned by the single user. e.g.


    Code
    namei -l /srv/dev-disk-by-uuid-1234/Software
    f: /srv/dev-disk-by-uuid-1234/Software
    drwxr-xr-x root root /
    drwxr-xr-x root root srv
    drwx------ original_user 1000 dev-disk-by-uuid-1234
    drwxrwsr-x root users Software


    Running:


    Code
    sudo chmod o+x /srv/dev-disk-by-uuid-1234


    Fixed it for me.

    I thought I would come back here and say I moved the test setup to another server with PCIe 3.0.

    I thought for sure real world speeds would be higher. And it's interesting that the NVMe is still the bottleneck on the 10GbE network when writing.


    This is using a PCIe NVMe adaptor in a Dell R620


    iperf3 Results

    iperf3 client RAM > Server NVMe File over 10GbE Network 5.76 Gbits/sec (PCIe 3.0)
    iperf3 client RAM > Server RAM over 10GbE Network 9.90 Gbits/sec



    DD Local Result (I can't actually tell how to read this - is it 1.1 GB/s or 785 MB/s??

    ryecoaaron


    What a mess. I don't understand how it got this way though. Why did all my in-use drives suddenly get quota entries in config and fstab? This was a clean install of OMV 6. The drives were formatted previously in OMV5 (couldn't wipe as were used for Greyhole and full of data).


    Note: If anyone comes back in the future (I may come across this myself again on the next rebuild) the quota files/dir are in the root of each drive/filesystem.

    I can see why this forced Greyhole into filling up my drives too. I obviously didn't notice a couple of file systems didn't mount properly and GH saw the drives as missing and tried to rebuild the required number of copies across the remaining drives. What a mess. I don't understand how it got this way though. Why did all my in-use drive suddenly get quota entries in config and fstab? This was a clean install of OMV 6.

    They are created because of the fstab options that are for quotas. If you don't want them, remove the options from the mntent entry in the database for the filesystem.

    Sorry about reviving but I'm having this issue too. I remove the options in the cfg file (the ones shown in the screenshot of the config file below) but they are still present (and in the fstab) after a reboot. Why do they keep coming back? Exactly what files or entries do I need to remove to stop this breaking 500 error when mounting new filesystems? I have been going round in circles for a couple of days.




    My other post:

    Seems like it's not just me?

    I found something that might help, but I'm not sure. If you do make sure before making a backup copy of your config.xml.

    Thanks for the lead. Though I have never used quota, nor have a quota section in my config file. I do see quota mentioned in my fstab above. BUt that's just probably default config.


    Edit: I removed the group and user section for each drive in fstab, rebooted and no improvement. I was able to back out/undo of the bogus changes (in yellow), wipe a test disk, create a file system. But when I went to mount that file system the bogus pending changes were back, and I got the 500 error. Looks like the new file system is mounted though, when I checked `lsblk`.

    When I try to save a GUI change I get this error:


    In pages of stack trace and repetitions of this error.


    Code
    stderr': 'quotacheck: Your kernel probably supports ext4 quota feature but you are using external quota files. Please switch your filesystem to use ext4 quota feature as external quota files on ext4 are deprecated.\nquotacheck: Scanning /dev/sdh1 [/srv/dev-disk-by-uuid-5f9cb8eb-de94-440d-85bc-13b603bdb445] quotacheck: Checked 5816 directories and 159746 files\nquotacheck: Cannot create new quotafile /srv/dev-disk-by-uuid-5f9cb8eb-de94-440d-85bc-13b603bdb445/aquota.user.new: File exists\nquotacheck: Cannot initialize IO on new quotafile: File exists\nquotacheck: Cannot create new quotafile /srv/dev-disk-by-uuid-5f9cb8eb-de94-440d-85bc-13b603bdb445/aquota.group.new: File exists\nquotacheck: Cannot initialize IO on new quotafile: File exists'} in /usr/share/php/openmediavault/system/process.inc:220

    I removed all SMART monitoring. Though, it was hard to tell if the removed disk was in the list. I got a 500 error when applying the change but on reload none are monitored.


    I also ran the other command. But I had run that previously from other research. These old drives are obviously referenced somewhere if I'm getting alerts via email.



    Code
    root@openmediavault:~# sudo cat /etc/openmediavault/config.xml | grep 59f18381
    root@openmediavault:~#