When I try to delete the remote-mounted drive I get
If you've shared the remote mount, meaning if you've attached some other service to it like creating a shared folder using the mount, you won't be able to delete it.
You'll have to remove the attached service first.
A zillion thanks for upgrading remote mount. I use it extensively on my OMV5 box where the remote mounts are shares located on a windows 10 box. With the latest OMV6 version, I can remote mount the shares on the W10 box with the fstab box checked and the same user/password as on the OMV5 system.
My OMV6 system is running from a flash drive on an old laptop. One very mild inconvenience that after deleting the remote mount plugin, it seems to take davfs2 with it so that has to be re-installed along with the updated remote mount plugin.
Again many thanks for the time you have put into omv-extras
crkm
One very mild inconvenience that after deleting the remote mount plugin, it seems to take davfs2 with it so that has to be re-installed along with the updated remote mount plugin.
Why should the filesystem stay around after removing the plugin? The omv web interface couldn't use it since the backend was removed. Even some of the packages that davfs2 needs would be removed. That is how OMV works.
with the fstab box checked
Why did you check this box?
When I try to delete the remote-mounted drive I get :
new package uploaded.
If you've shared the remote mount, meaning if you've attached some other service to it like creating a shared folder using the mount, you won't be able to delete it.
You'll have to remove the attached service first.
The code was broken. I have fixed in the latest upload.
Why should the filesystem stay around after removing the plugin? The omv web interface couldn't use it since the backend was removed. Even some of the packages that davfs2 needs would be removed. That is how OMV works.
Why did you check this box?
Checked fstab box as per #555 (and I was getting error messages with the fstab box checked on earlier versions). Thanks for the davfs2 explanation. BTW, all remote mounts still there after a reboot.
Thanks again.
Checked fstab box as per #555
Ok. The uploaded package is changing a lot. So, I wouldn't read older poss on workarounds for bugs. I would rather fix the bug. Glad it is surviving reboots.
The code was broken. I have fixed in the latest upload
I must have pulled the latest.
Great! Now it works fine.
@ryecoaaron: Thanks to you, this night, for the first time, I am backuping a W10 disk on a drive mount on a Raspberry 2 through OMV+Remote-mount+ Rsync.
fx
Thanks to you, this night, for the first time, I am backuping a W10 disk on a drive mount on a Raspberry 2 through OMV+Remote-mount+ Rsync.
Good to hear that things work once in a while : ) Is the fstab checkbox checked or not?
I currently have two remote mounts set up on my OMV6 system described above with the latest version of remote mount. I ticked the fstab checkbox on one but not the other. No problems or errors in setting them up and setting them as shares.
After rebooting through the OMV Web GUI, both remote mounts and shares are still there in the Web GUI as set up.
Thanks again!
I set up two additional remote mounts (fstab checkbox not checked) on my W10 box, set them as shares and set up a local rsync task to copy/sync from one to the other (total transfer ~0.5GB). Worked perfectly.
As far as I can tell the current/latest OMV6 remote mount plugin has the same capability as the OMV5 version.
Checked.
Can you try with the box not checked? fstab is not the preferred method.
As far as I can tell the current/latest OMV6 remote mount plugin has the same capability as the OMV5 version.
Hopefully it is much better because of the systemd mount and automount (if fstab is unchecked). The mount should resolve dependencies on boot which should fix the not mounting on boot problem. The automount file should remount the filesystem if the remote system is rebooted or offline for a while.
Hopefully it is much better because of the systemd mount and automount (if fstab is unchecked). The mount should resolve dependencies on boot which should fix the not mounting on boot problem. The automount file should remount the filesystem if the remote system is rebooted or offline for a while.
Great news! I'm more than happy to run more tests if it is helpful.
Thanks again
crkm
I'm more than happy to run more tests if it is helpful.
I would just like to see if you have the same experience with the fstab checkbox unchecked. Try rebooting the remote Win system to see how the automount works. The fstab checkbox being checked should not recover from a remote system outage.
I would just like to see if you have the same experience with the fstab checkbox unchecked. Try rebooting the remote Win system to see how the automount works. The fstab checkbox being checked should not recover from a remote system outage.
Rebooting the W10 box did not affect the remote mounts on my OMV6 system (or my main OMV5 system). The OMV6 remote mounts have the fstab checkbox unchecked (#575). The rsync task ran without problem to resync the two remote mounts (small data transfer) on the OMV6 system.
I'll set up additional remote mounts with the fstab checkbox checked (as ffxtv has) and see what happens when I reboot the W10 box. I'll also try turning off the W10 box completely for a short period (minutes)
crkm
I set up two additional remote mounts with the fstab box checked and set up one as a share. I did not remove the two remote mounts set up with the fstab checkbox unchecked.
I rebooted the W10 box, there was no change in any of the remote mounts or shares. I turned the W10 box off and then on again after ~10 minutes. Again, no change.
My OMV6 system turned off while I was out. The W10 box stayed on. On turning the OMV6 system back on the remote mounts and shares were all still present, ie no change.
Hope this helps
crkm
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
