config.xml - sharedfolderref

    • OMV 3.x
    • Upgrade 2.x -> 3.x
    • config.xml - sharedfolderref

      I upgraded my OMV2 backup server this evening - not my main server, and was hit with a couple of issues.

      1st, omv-extrasorg add-on didn't update during the upgrade process, so I needed to manually remove and re-add this.
      2nd, all the references to 'sharedfolderref' in config.xml no longer appear to be valid. As such, I had to manually remove the rsync jobs section and re-add the jobs one by one.

      Is there a reason why omv-extrasorg didn't update during the upgrade process?

      Is there a way to identify the updated sharedfolderref's so that I can substitute them in to the config.xml file and not have to re-create everything again?

      The reason I ask is that on my main server I notice a lot more sharedfolderref's for things like NFS etc. I'd much rather be able to fix these than delete them and create them all again.

      the sharedsharedfolder ref is a UUID, but it's not from blkid and I'm not sure where to find them. Can anyone help?

      Thanks.
    • What do you mean with sharedfolderref's are invalid? The shared folder configuration is not touched by the update.
      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
    • dojrude wrote:

      Is there a reason why omv-extrasorg didn't update during the upgrade process?
      The upgrade between 2.x and 3.x is a pain (the two versions are VERY different and the OS is a full upgrade). Lots of plugins don't upgrade correctly. That is why we recommend a fresh install.

      No idea why the sharedfolderrefs would change. I haven't seen that before.

      dojrude wrote:

      the sharedsharedfolder ref is a UUID, but it's not from blkid and I'm not sure where to find them. Can anyone help?
      They are randomly generated. If they are wrong in the mntent section of config.xml, there is no way to recover except from backup.
      omv 4.0.6 arrakis | 64 bit | 4.12 backports kernel | omvextrasorg 4.1.0
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please don't PM for support... Too many PMs!
    • So am I to understand that there is no way to identify the sharedfolderref's in the upgraded version?

      They may be randomly generated, but how do I identify them?

      Kind of defeats the update process if it breaks everything that references a sharedfolderref from the previous version. Why are they changing? Shouldn't they stay the same or be updated with the upgrade process.

      Seems like a fairly common problem, although I have to say that mine are still referenced in the correct tags and not as in the post below.
      Failed to execute XPath query '//system/shares/sharedfolder[uuid='']'

      Either way, the only way to fix rsync was to delete everything in config.xml between the jobs tags. Surely we should be able to modify the references to sharedfolderred''s and fix the problem.

      And what about omv-extrasorg? why doesn't that get upgraded during the update process as I'm sure nearly every user will have this add-on installed.
    • dojrude wrote:

      how do I identify them?
      Like I said, the uuid source of the sharedfolderef is in the mntent section.

      dojrude wrote:

      Kind of defeats the update process if it breaks everything that references a sharedfolderref from the previous version. Why are they changing? Shouldn't they stay the same or be updated with the upgrade process.
      As I and Volker both said, the update process should never touch those references.

      dojrude wrote:

      Seems like a fairly common problem
      One other post makes it common?

      dojrude wrote:

      And what about omv-extrasorg? why doesn't that get upgraded during the update process as I'm sure nearly every user will have this add-on installed.
      Look through the forum... We have repeatedly said the upgrade process does not go well between OMV 2.x and 3.x for various reasons (sysvinit to systemd change, omv 2.x to 3.x is a huge change especially to plugins,etc). That is why we recommend a fresh install. But in all the failures I have encountered in my own testing, I have never seen sharedfolderrefs change.
      omv 4.0.6 arrakis | 64 bit | 4.12 backports kernel | omvextrasorg 4.1.0
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please don't PM for support... Too many PMs!
    • Thanks, sorry I missed the mntent reference.

      I've decided a fresh install may be the best option for the main server as although I have omv-extras installed on the backup server, No additional addons have been installed and the only addon enabled and configured was rsync and It still took me an hour or so to resolve the issues from the upgrade process and get everything working again.