I don't use email notifications but you might need to have OMV notifications enabled and working in the GUI config before this will work as OMV will need to send the email via a mail server.
Posts by jata1
-
-
-
-
I already had this cron file commented out but it still ran armbian-ramlog
The only thing that I have found to stop it is to change the enabled flag in the default files below...
changed the enabled flag to false in etc/default/armbian-ramlog
changed the enabled flag to false in etc/default/armbian-zram-config
-
-
Disabling the service means the value in the default files doesn't matter.
I changed the values back to enabled in the default files and rebooted. After reboot the services do not start (as expected) but the armbian-ramlog does execute logrotate and this prevents OMV logrotate from working.
Changed the enabled setting back to disabled and rebooted. Now everything fine again. So long story short is that you do need to do all of the following to fully disable armbian-ramlog
systemctl disable armbian-ramlog
systemctl disable armbian-zram-config
changed the enabled flag to false in etc/default/armbian-ramlog
changed the enabled flag to false in etc/default/armbian-zram-config
commented out all lines in etc/cron.daily/armbian-ram-logging
-
Thanks. The issue is that the FTP service starts on reboot even when disabled using systemctl disable and also disabled in the GUI.
I think there could be a bug in the logic the controls the service. If I enable the FTP service in GUI and restart, then proftpd is disabled.
-
all good. thanks for the help.
Any chance you can help with my last outstanding issue? see thread below
-
Strange that the service does run on my clean install(s) of Armbian rock64 with OMV script. I am using latest Buster 5.4 image from the armbian website.
Have you done a install using latest build?
It is all fine now as I have disabled manually but it could affect others so I thought I would report it here.
-
I have tried but the command does not stop the service - see below.
-
Thanks for the help. Much appreciated.
Yes it is running when I check status using systemctl status proftpd - but according to the configuration it should not be running as it was off and disabled prior to the reboot.
If I enable and disable the service using the GUI, proftpd is correctly sopped and disabled
when I do a restart, I am back to the same situation so I really would like to find and resolve the root issue.
Happy Easter everyone.
-
I reported this issue a while ago but I still have the same issue.
FTP service (proftpd) starts on boot even when disabled
If I disable FTP service and reboot then I get a red light on the running indicator for the FTP service.
If I enable FTP and restart then I get green light on running indicator but enabled is grey.
So I think there might be a bug in the code/logic that enables/disables the FTP service.
I'm happy to investigate but I need some help to get started
screen shot of status after reboot with FTP service disabled/off
-
ryecoaaron I use the install script and I don't think it is disabling armbian-ramlog. On rock64 buster with kernel 5.4 it is not disabling and I have done around 5 clean installs over the last month or so. I'm using the script below.
https://github.com/OpenMediaVa…Script/raw/master/install | sudo bash
I noticed this issue and after a bit of investigating, I have disabled armbian-ramlog manually and logrotate is working fine now.
forgot to say that I used this thread to work out how to disable ramlog
https://forum.armbian.com/topi…an-ram-logging-correctly/
In summary, I did the following and then did a reboot
systemctl disable armbian-ramlog
systemctl disable armbian-zram-config
changed the enabled flag to false in etc/default/armbian-ramlog
changed the enabled flag to false in etc/default/armbian-zram-config
commented out all lines in etc/cron.daily/armbian-ram-logging
-
I am currently looking into ram logging on my rock64 running Armbian 5.4 Buster.
Armbian uses armbian-ramlog that I think uses log2ram
The OMV config I use has the folder2ram plugin enabled. I'm not sure both are needed and I have issues with logrotate at the moment.
I have disabled armbian-ramlog and will see how things work over the next couple of days and report back.
Is your NanoPi running armbian?
-
Understood. Maybe having a GUI page for Advance/Custom settings that allows people to modify/add some of these settings to make it easier for less technical users (feature request) .
I think editing the announcement name for SMB Ito use just the hostname (without - SMB etc at the end) would be quite a good example and I am sure there are others.
Very happy with OMV5 so great work and thanks.
-
thanks votdev ... I was being dumb
-
I'm trying to customise the announcement name for the smb service. I tried editing the file /etc/avahi/services/smb.service
removed the 'SMB/CIFS' in the name and then ran the following but it didn't seem to work.
omv-salt stage run prepare
omv-salt deploy run avahi
Sorry if I'm being dumb but what am I missing...
-
service via environment variable.
-
Hi,
I added a usb drive to my OMV server and was planning to copy data to it from another drive in the same OMV server (rock64). I changed my mind so unmounted the file system un the OMV GUI and removed it. then rebooted the server
Now my system is logging the following in the syslog Avery few minutes.
I have checked etc/fstab and this looks fine.
What else can I check/remove to clean this up?
Thanks!
Feb 20 12:53:40 rock64 monit[1590]: Filesystem '/srv/dev-disk-by-label-USBArchive' not mounted
Feb 20 12:53:40 rock64 monit[1590]: 'filesystem_srv_dev-disk-by-label-USBArchive' unable to read filesystem '/srv/dev-disk-by-label-USBArchive' state
Feb 20 12:53:40 rock64 monit[1590]: 'filesystem_srv_dev-disk-by-label-USBArchive' trying to restart
Feb 20 12:53:40 rock64 monit[1590]: 'mountpoint_srv_dev-disk-by-label-USBArchive' status failed (1) -- mountpoint: /srv/dev-disk-by-label-USBArchive: No such file or directory -
glad it worked. Also using linux shell commands is very fast and clean way to delete / move / copy (but do it carefully)
