Hello,
have an OMV 4.1.24-1 running since about half a year. OMV is accessed for users via smb/cifs and sftp(omv-extras installed). Since the server is in a non-safe environment (access by other people I know, but I do not trust completely) I also use the luksencryption plug-in (omv-extras). Users home folders are enabled.
Installed the following updates yesterday:
CRON-APT RUN [/etc/cron-apt/config]: Wed Sep 18 04:00:01 CEST 2019 CRON-APT SLEEP: 1192, Wed Sep 18 04:19:53 CEST 2019 CRON-APT ACTION: 3-download CRON-APT LINE: /usr/bin/apt-get -o Acquire::http::Dl-Limit=25 dist-upgrade -d -y -o APT::Get::Show-Upgraded=true Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following packages will be upgraded:
firmware-amd-graphics firmware-atheros firmware-bnx2 firmware-bnx2x
firmware-brcm80211 firmware-cavium firmware-intel-sound firmware-intelwimax
firmware-ipw2x00 firmware-ivtv firmware-iwlwifi firmware-libertas
firmware-linux firmware-linux-nonfree firmware-misc-nonfree firmware-myricom
firmware-netxen firmware-qlogic firmware-realtek firmware-samsung
firmware-siano firmware-ti-connectivity openmediavault
23 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/38.7 MB of archives.
After this operation, 1713 kB of additional disk space will be used.
Download complete and in download only mode
Alles anzeigen
After reboot the startup was delayed by the following service:
However, it finally started. Than I received the following notifications:
Status failed Service mountpoint_srv_dev-disk-by-label-Data
Date: Wed, 18 Sep 2019 09:07:48
Action: alert
Host: xxx
Description: status failed (1) -- /srv/dev-disk-by-label-Data is not a mountpoint
Your faithful employee,
Monit
Alles anzeigen
Filesystem flags changed Service filesystem_srv_dev-disk-by-label-Data
Date: Wed, 18 Sep 2019 09:08:48
Action: alert
Host: xxx
Description: filesystem flags changed to 0x1008
Your faithful employee,
Monit
Alles anzeigen
Than, I decrypted the luks encrypted storage but observed that all shared under /sharedfolders/<share> are empty. This can be solved by adding another "test" share. After a reboot all folder for shares unter /sharedfolders are empty again. Data unter /srv/dev[...]/ remains untouched.
However, the SFTP plug-in showed some strange behaviour. The access list contained the folder homes several times. Moreover, user told me that they can't access their home folders. So I deleted all entries for homes and re-added them (not all users are in the list of sftp users). This actually deleted all home folders, which was an unexpected behaviour to me. Fortunately, all home folders are backuped daily.
I uninstalled the sftp plugin. Now the /sftp/<user>/<share> are empty but still exist. There are also still entries for sftp in fstab.
Is there a solution to the "empty /sharedfolders/<share>" problem after reboot? How may I get sftp running again?
cheers
Thermo
PS: sorry for double post. received error with id 4851be6be597751aab5f544072bcfa0fa838810d an tried again.