Filesystem flags changed to 0x1008 and quota service related errors

  • Hello all.


    I need to turn off the quota service and remove the aquota.user and aquota.group files from the root of my disks, so I can give permissions to all folders from root, instead of going one by one (for some reason I cannot delete them logged as root either change their ownership and permissions, I guess because they are system service files).


    So I have done the following steps:


    1. quotaoff -a


    The output of this command was none, but it seems to have worked as it was idle for around 10 minutes.


    2. systemctl disable quota


    The output of this command was full of errors I do not understand:


    Code
    Synchronizing state of quota.service with SysV service script with /lib/systemd/systemd-sysv-install.
    Executing: /lib/systemd/systemd-sysv-install disable quota
    insserv: warning: current start runlevel(s) (empty) of script `quota' overrides LSB defaults (S).
    insserv: warning: current stop runlevel(s) (0 6 S) of script `quota' overrides LSB defaults (0 6).
    insserv: warning: current start runlevel(s) (empty) of script `quota' overrides LSB defaults (S).
    insserv: warning: current stop runlevel(s) (0 6 S) of script `quota' overrides LSB defaults (0 6).


    After these 2 commands, 10 out of 12 disks got correctly their quota service turned off, as, after a remount and a reboot, there were no aquota.user and aquota.group files in their root.


    But there are 2 disks that still have quota enabled somehow (maybe because of the errors above).


    So I manually edited the /etc/openmediavault/config.xml file, and substitute the chain usrjquota=aquota.user,grpjquota=aquota.group by noquota on all the disks, and make a


    3. omv-mkconf fstab.


    I remounted the disks, reboot, and the /etc/fstab shows the disk correctly as noquota



    The id of the disks with the aquota.user and aquota.group present are "series3" and "multimedia1" (I cannot find any difference with the other disks and I don't know why these 2 still have those files on root), and I cannot remove them or change ownership.


    Watching the logs from monit service I have seen some warnings about filesystem flags being changed (I never got this error before), curiously for disks "series3" and "multimedia1" which are the ones with the quota files still in them.


    Code
    monit alert --  Filesystem flags changed filesystem_srv_dev-disk-by-label-series3 on the Fri, 15 Mar 2019 19:05:45 GMT
    
    
    Filesystem flags changed Service filesystem_srv_dev-disk-by-label-series3
    
    
    Date:        Fri, 15 Mar 2019 20:05:45
    Action:      alert
    Host:        olmos13nas
    Description: filesystem flags changed to 0x1008


    Code
    monit alert --  Filesystem flags changed filesystem_srv_dev-disk-by-label-multimedia1 on the Fri, 15 Mar 2019 19:05:47 GMT
    
    
    Filesystem flags changed Service filesystem_srv_dev-disk-by-label-multimedia1
    
    
    Date:        Fri, 15 Mar 2019 20:05:47
    Action:      alert
    Host:        olmos13nas
    Description: filesystem flags changed to 0x1008


    Which is the command to check if the quota service is still on? I tried quotacheck but it results as an error.


    Thanks in advance.


    Any other output or log needed, just ask me for it.

    omv 5.5.23-1 usul arm64

    omv 5.5.23-1 usul x64


  • I am making some improvements.


    I have tried the following:


    Unmount the 2 disks with quotaon
    service quota start
    quota on -a (all filesystems)
    Mount the 2 disks with quotaon
    Reboot system


    This way I have the service quota started and running, and the files aquota.user and aquota.group generated in the root of all 12 disks.


    So from here I did the reverse procedure:


    service quota stop
    quotaoff -a (all filesystems)
    Reboot system


    And I still got the same 2 disks with residual quota files which I cannot -rm or -chown. If I enter repquota -a the 2 disks show as if they still have the quota service running:


    omv 5.5.23-1 usul arm64

    omv 5.5.23-1 usul x64


  • Got it.


    It was the sftp plugin. I uninstalled it, removed sftp user/stp-access group, shares, privileges and ACL and I finally could remove the damned files so I can give global permissions to the disks.

    omv 5.5.23-1 usul arm64

    omv 5.5.23-1 usul x64


Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!