Problems and Questions about Shared Folders

namirda · 28. Mai 2018

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:

Code

neil@rock64:/sharedfolders$ df /sharedfolders/backup
Filesystem     1K-blocks     Used Available Use% Mounted on
/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

Code

neil@rock64:/sharedfolders$ df /sharedfolders/backup
Filesystem     1K-blocks    Used Available Use% Mounted on
/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

votdev · 28. Mai 2018

Zitat von namirda

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.

Zitat von namirda

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.

Zitat von namirda

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.

namirda · 28. Mai 2018

Zitat von votdev

A feature that is not implemented

Nice one....! Would be a nice feature wouldn't it..???.....

Thanks for the reply - mountpoint is just what I need.

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?

N

votdev · 28. Mai 2018

Zitat von namirda

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

Code

# mount -a

and everything should work as expected.

namirda · 29. Mai 2018

Zitat von votdev

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 :

Code

neil@rock64:~$
neil@rock64:~$ ls -al /sharedfolders/backup
total 20
drwxr-sr-x   5 root users 4096 May 28 10:21 .
drwxr-xr-x   4 root root  4096 May 29 10:23 ..
drwxr-xr-x  10 root root  4096 May 26 10:28 docker
drwxr-xr-x 104 root root  4096 May 28 19:17 etc
drwxr-xr-x   3 root root  4096 May 25 20:27 home
neil@rock64:~$
neil@rock64:~$ df /sharedfolders/backup
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/sda1       95625896 46184108  49425404  49% /sharedfolders/backup
neil@rock64:~$
neil@rock64:~$ mountpoint /sharedfolders/backup
/sharedfolders/backup is a mountpoint
neil@rock64:~$
neil@rock64:~$ # Here I unplug the disk
neil@rock64:~$
neil@rock64:~$ df /sharedfolders/backup
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/mmcblk0p7  29861840 4025764  24582568  15% /
neil@rock64:~$
neil@rock64:~$ ls -al /sharedfolders/backup
total 8
drwxr-xr-x 2 root root 4096 May 28 18:40 .
drwxr-xr-x 4 root root 4096 May 29 10:23 ..
neil@rock64:~$
neil@rock64:~$ mountpoint /sharedfolders/backup
/sharedfolders/backup is not a mountpoint
neil@rock64:~$
neil@rock64:~$ Here I reconnect the disk
-bash: Here: command not found
neil@rock64:~$
neil@rock64:~$ ls -al /sharedfolders/backup
total 8
drwxr-xr-x 2 root root 4096 May 28 18:40 .
drwxr-xr-x 4 root root 4096 May 29 10:23 ..
neil@rock64:~$
neil@rock64:~$ df /sharedfolders/backup
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/mmcblk0p7  29861840 4025916  24582416  15% /
neil@rock64:~$
neil@rock64:~$ mountpoint /sharedfolders/backup
/sharedfolders/backup is not a mountpoint
neil@rock64:~$
neil@rock64:~$ sudo mount -a
[sudo] password for neil:
neil@rock64:~$
neil@rock64:~$ ls -al /sharedfolders/backup
total 8
drwxr-xr-x 2 root root 4096 May 28 18:40 .
drwxr-xr-x 4 root root 4096 May 29 10:23 ..
neil@rock64:~$
neil@rock64:~$ df /sharedfolders/backup
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/mmcblk0p7  29861840 4025964  24582368  15% /
neil@rock64:~$
neil@rock64:~$ mountpoint /sharedfolders/backup
/sharedfolders/backup is not a mountpoint
neil@rock64:~$
neil@rock64:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            2.0G     0  2.0G   0% /dev
tmpfs           393M  6.0M  387M   2% /run
/dev/mmcblk0p7   29G  3.9G   24G  15% /
tmpfs           2.0G     0  2.0G   0% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           2.0G     0  2.0G   0% /sys/fs/cgroup
tmpfs           2.0G     0  2.0G   0% /tmp
/dev/mmcblk0p6  100M   48M   53M  48% /boot/efi
tmpfs           393M     0  393M   0% /run/user/1000
/dev/sdb1        92G   45G   48G  49% /srv/dev-disk-by-label-disk1
neil@rock64:~$ ^C

Alles anzeigen

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

votdev · 29. Mai 2018

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.

namirda · 29. Mai 2018

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:

Code

$cat /etc/systemd/system/sharedfolders-backup.automount


[Unit]
Description=Automount backup shared folder


[Automount]
Where=/sharedfolders/backup


[Install]
WantedBy=local-fs.target

Alles anzeigen

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

votdev · 29. Mai 2018

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.

votdev · 29. Mai 2018

See https://github.com/openmediavault/openmediavault/issues/114

namirda · 30. Mai 2018

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

Jetzt mitmachen!