Problems and Questions about Shared Folders

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Problems and Questions about Shared Folders

      I have a Shared Folder called "backup" on device "disk1" which is mounted on /dev/sda1 - all configured using the OMV GUI.

      The command df shows the following as expected:

      Source Code

      1. neil@rock64:/sharedfolders$ df /sharedfolders/backup
      2. Filesystem 1K-blocks Used Available Use% Mounted on
      3. /dev/sda1 95625896 46183644 49425868 49% /sharedfolders/backup
      If for some reason "disk1" goes offline then it shows as "Missing" in the GUI and df now shows

      Source Code

      1. neil@rock64:/sharedfolders$ df /sharedfolders/backup
      2. Filesystem 1K-blocks Used Available Use% Mounted on
      3. /dev/mmcblk0p7 29861840 4010624 24597708 15% /

      So now /sharedfolders/backups is mounted on /. However if I look at the share in the GUI it still shows the share as being on /dev/disk/by-label/disk1 - nothing has changed there!

      As a result of this, my daily backups which write to /sharedfolders/backup were written to the root directory rather than /dev/sda1 - you can guess what happened!

      I would have expected/hoped that the backup job would fail because /sharedfolders/backup no longer exists - but instead it created the directory /sharedfolders/backup on / and ran the job as normal.

      If the missing drive is subsequently reconnected, it is detected by OMV and re-mounted but the mount point for the share is not updated. So even after the drive is reconnected, the daily backups will continue to be written to /. I think the only way to correct it is to delete and then re-create the share.

      So 3 questions:

      1) Is it a bug that the mount point /sharedfolders/backup is not removed when disk1 becomes unavailable??
      2) Is it another bug that the mount point is not re-created when the disk is reconnected?
      3) How should scripts check for correct mounting of shared folders before writing to them?

      Thanks

      N

      The post was edited 1 time, last by namirda ().

    • namirda wrote:

      1) Is it a bug that the mount point /sharedfolders/backup is not removed when disk1 becomes unavailable??
      No. You should get notified from monit via email that the filesytem is missing.


      namirda wrote:

      2) Is it another bug that the mount point is not re-created when the disk is reconnected?
      No bug, but a feature that is not implemented. But you should get an email from monit that the disk is back, so you could manually do the necessary action.


      namirda wrote:

      3) How should scripts check for correct mounting of shared folders before writing to them?
      The rsync and usb-backup plugin already checks if the target mount point exists. If you have your own scrripts, then have a look at the CLI tool called mountpoint.
      Absolutely no support through PM!

      I must not fear.
      Fear is the mind-killer.
      Fear is the little-death that brings total obliteration.
      I will face my fear.
      I will permit it to pass over me and through me.
      And when it has gone past I will turn the inner eye to see its path.
      Where the fear has gone there will be nothing.
      Only I will remain.

      Litany against fear by Bene Gesserit
    • namirda wrote:

      Is it really necessary to delete and then recreate the share to get the mount point corrected - that is quite a hassle if there are lots of references to it?
      I don't understand you. Simply do a

      Source Code

      1. # mount -a
      and everything should work as expected.
      Absolutely no support through PM!

      I must not fear.
      Fear is the mind-killer.
      Fear is the little-death that brings total obliteration.
      I will face my fear.
      I will permit it to pass over me and through me.
      And when it has gone past I will turn the inner eye to see its path.
      Where the fear has gone there will be nothing.
      Only I will remain.

      Litany against fear by Bene Gesserit
    • votdev wrote:

      and everything should work as expected

      Perhaps I'm missing something here - but it really doesn't work as I expected. Please take a look at the following :

      Source Code

      1. neil@rock64:~$
      2. neil@rock64:~$ ls -al /sharedfolders/backup
      3. total 20
      4. drwxr-sr-x 5 root users 4096 May 28 10:21 .
      5. drwxr-xr-x 4 root root 4096 May 29 10:23 ..
      6. drwxr-xr-x 10 root root 4096 May 26 10:28 docker
      7. drwxr-xr-x 104 root root 4096 May 28 19:17 etc
      8. drwxr-xr-x 3 root root 4096 May 25 20:27 home
      9. neil@rock64:~$
      10. neil@rock64:~$ df /sharedfolders/backup
      11. Filesystem 1K-blocks Used Available Use% Mounted on
      12. /dev/sda1 95625896 46184108 49425404 49% /sharedfolders/backup
      13. neil@rock64:~$
      14. neil@rock64:~$ mountpoint /sharedfolders/backup
      15. /sharedfolders/backup is a mountpoint
      16. neil@rock64:~$
      17. neil@rock64:~$ # Here I unplug the disk
      18. neil@rock64:~$
      19. neil@rock64:~$ df /sharedfolders/backup
      20. Filesystem 1K-blocks Used Available Use% Mounted on
      21. /dev/mmcblk0p7 29861840 4025764 24582568 15% /
      22. neil@rock64:~$
      23. neil@rock64:~$ ls -al /sharedfolders/backup
      24. total 8
      25. drwxr-xr-x 2 root root 4096 May 28 18:40 .
      26. drwxr-xr-x 4 root root 4096 May 29 10:23 ..
      27. neil@rock64:~$
      28. neil@rock64:~$ mountpoint /sharedfolders/backup
      29. /sharedfolders/backup is not a mountpoint
      30. neil@rock64:~$
      31. neil@rock64:~$ Here I reconnect the disk
      32. -bash: Here: command not found
      33. neil@rock64:~$
      34. neil@rock64:~$ ls -al /sharedfolders/backup
      35. total 8
      36. drwxr-xr-x 2 root root 4096 May 28 18:40 .
      37. drwxr-xr-x 4 root root 4096 May 29 10:23 ..
      38. neil@rock64:~$
      39. neil@rock64:~$ df /sharedfolders/backup
      40. Filesystem 1K-blocks Used Available Use% Mounted on
      41. /dev/mmcblk0p7 29861840 4025916 24582416 15% /
      42. neil@rock64:~$
      43. neil@rock64:~$ mountpoint /sharedfolders/backup
      44. /sharedfolders/backup is not a mountpoint
      45. neil@rock64:~$
      46. neil@rock64:~$ sudo mount -a
      47. [sudo] password for neil:
      48. neil@rock64:~$
      49. neil@rock64:~$ ls -al /sharedfolders/backup
      50. total 8
      51. drwxr-xr-x 2 root root 4096 May 28 18:40 .
      52. drwxr-xr-x 4 root root 4096 May 29 10:23 ..
      53. neil@rock64:~$
      54. neil@rock64:~$ df /sharedfolders/backup
      55. Filesystem 1K-blocks Used Available Use% Mounted on
      56. /dev/mmcblk0p7 29861840 4025964 24582368 15% /
      57. neil@rock64:~$
      58. neil@rock64:~$ mountpoint /sharedfolders/backup
      59. /sharedfolders/backup is not a mountpoint
      60. neil@rock64:~$
      61. neil@rock64:~$ df -h
      62. Filesystem Size Used Avail Use% Mounted on
      63. udev 2.0G 0 2.0G 0% /dev
      64. tmpfs 393M 6.0M 387M 2% /run
      65. /dev/mmcblk0p7 29G 3.9G 24G 15% /
      66. tmpfs 2.0G 0 2.0G 0% /dev/shm
      67. tmpfs 5.0M 4.0K 5.0M 1% /run/lock
      68. tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup
      69. tmpfs 2.0G 0 2.0G 0% /tmp
      70. /dev/mmcblk0p6 100M 48M 53M 48% /boot/efi
      71. tmpfs 393M 0 393M 0% /run/user/1000
      72. /dev/sdb1 92G 45G 48G 49% /srv/dev-disk-by-label-disk1
      73. neil@rock64:~$ ^C
      Display All
      Initially I look at my backup folder which is a shared folder created in OMV. In line 12 it is mounted on /dev/sda1 and line 15 confirms it is a mountpoint

      I then unplug the disk and repeat - as expected the shared folder is now mounted on / and /sharedfolders/backup is no longer a mountpoint

      I then reconnect the disk and, as I now expect, your unimplemented feature does not repair the mountpoint on /sharedfolders/backup

      Finally I do "sudo mount-a" s you suggested - but the mountpoint on /sharedfolders/backup is not repaired and so everything does not work as expected

      You can see from the df -h in line 61 that the disk has been remounted, this time as /dev/sdb1 but the mountpoint is not repaired.

      So I don't think that simply doing mount -a will make everything work as expected. I think you need to mount all the shares on the disk individually.?

      Thanks

      N

      The post was edited 1 time, last by namirda ().

    • I'm sorry, my mistake. The shared folders are processed different. They are systemd mount units, e.g. check /etc/systemd/system/sharedfolders-backup.mount. Normally systemd should take care about the handling of this mount point. If the device defined under 'What' comes back, systemd should take care about the mount point. Would be great if you could have a deeper look into this issue and maybe contribute your knowledge via patch or something else.
      Absolutely no support through PM!

      I must not fear.
      Fear is the mind-killer.
      Fear is the little-death that brings total obliteration.
      I will face my fear.
      I will permit it to pass over me and through me.
      And when it has gone past I will turn the inner eye to see its path.
      Where the fear has gone there will be nothing.
      Only I will remain.

      Litany against fear by Bene Gesserit
    • Hi Volker,

      Thanks for the reply.

      I have been looking into this problem a little already. The issue is that as well as the systemd mount unit you also need a systemd automount unit which should contain something like the following:

      Source Code

      1. $cat /etc/systemd/system/sharedfolders-backup.automount
      2. [Unit]
      3. Description=Automount backup shared folder
      4. [Automount]
      5. Where=/sharedfolders/backup
      6. [Install]
      7. WantedBy=local-fs.target
      I have tried this out and it seems to work for me. You need to autogenerate the automount unit file at the same time as you generate the mount unit file.

      The mount service can then be disabled - the automount service handles it all

      I hope that helps

      N
    • Hmmm, right, i remember there was something with automount. I think there was a reason i did not create the .automount file, maybe systemd will create the mount point immediatelly after the file was created; but this behaviour does not fit in the workflow OMV creates and starts/stops services. I think this behaviour does fit into the new workflow of OMV5 where Salt is used to create configrations and manage services.
      Absolutely no support through PM!

      I must not fear.
      Fear is the mind-killer.
      Fear is the little-death that brings total obliteration.
      I will face my fear.
      I will permit it to pass over me and through me.
      And when it has gone past I will turn the inner eye to see its path.
      Where the fear has gone there will be nothing.
      Only I will remain.

      Litany against fear by Bene Gesserit
    • Absolutely no support through PM!

      I must not fear.
      Fear is the mind-killer.
      Fear is the little-death that brings total obliteration.
      I will face my fear.
      I will permit it to pass over me and through me.
      And when it has gone past I will turn the inner eye to see its path.
      Where the fear has gone there will be nothing.
      Only I will remain.

      Litany against fear by Bene Gesserit
    • Just in case anybody else is thinking of using my proposed .automount unit file mentioned in a previous post, please note that while it does work it also has two unfortunate side-effects:

      1) The 'mountpoint' command which was pointed out to me by votdev no longer seems to work - it reports that /sharedfolders/backup is a mountpoint even when the disk is disconnected.

      2) If you try to access the shared folder (by using rsync for example) then it hangs for 90 seconds before returning a "no such device" message. This is a lot better than previously when it simply wrote stuff in the wrong place but it would be nice if you could change the timeout interval - I don't believe that you can!

      I have yet to find a way to determine if a shared folders is actually available or not other than simply trying and then waiting 90 seconds for an answer!

      N
    • namirda wrote:

      Hi Volker,

      Thanks for the reply.

      I have been looking into this problem a little already. The issue is that as well as the systemd mount unit you also need a systemd automount unit which should contain something like the following:

      Source Code

      1. $cat /etc/systemd/system/sharedfolders-backup.automount
      2. [Unit]
      3. Description=Automount backup shared folder
      4. [Automount]
      5. Where=/sharedfolders/backup
      6. [Install]
      7. WantedBy=local-fs.target
      I have tried this out and it seems to work for me. You need to autogenerate the automount unit file at the same time as you generate the mount unit file.

      The mount service can then be disabled - the automount service handles it all

      I hope that helps

      N
      nice, in relation to that also see
      Systemd: (Auto-) Mount cifs shares
      michlstechblog.info/blog/syste…examples-for-cifs-shares/


      "....
      Create the mount point


      root@debdev:~# mkdir /mnt/mp

      Create the systemd definition file. The Folder for custom systemd unit files is /etc/systemd/system.
      Create a new file mnt-mp.mount in the diretory /etc/systemd/system. The filename must contain the mountpointname where the slashes are replaced with “minus”. Filename for /mnt/mp => mnt-mp.mount
      If this does not match you will get an error like:

      root@debdev:~# journalctl |grep storage
      storage-cifs.mount's Where= setting doesn't match unit name. Refusing.

      This is a working unit
      [Unit] Description=cifs mount script Requires=network-online.target After=network-online.service[Mount] What=//192.168.56.1/mp$ Where=/mnt/mp Options=username=yourCifsUser,password=Secretpassword,workgroup=YourDomain,rw Type=cifs[Install] WantedBy=multi-user.targetEnable the previous defined config and check if error occurs.

      systemctl enable mnt-mp.mount
      systemctl status mnt-mp.mount

      Update: From security reasons newer Kernel releases does not allow to connect to CIFS Share that only supports SMB1. Error Message: No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1).
      To mount such shares you have to explict set the SMB protocol version to 1 by add the option vers=1.0 to the Options line in the mount unit. For example:
      Options=username=yourCifsUser,password=Secretpassword,workgroup=YourDomain,rw,vers=1.0
      To mount and unmount your share start or stop the unit.

      root@debdev:~# systemctl start mnt-mp.mount
      root@debdev:~# mount|grep 192
      //192.168.56.1/mp$ on /mnt/mp type cifs (rw,relatime,vers=1.0,cache=strict,username=yourCifsUser,.....
      root@debdev:~# systemctl stop mnt-mp.mount

      If you make changes to your unit file while its still active, call

      systemctl daemon-reload

      to reload it...."