Error when deleting shared folder

    • OMV 4.x
    • Resolved
    • buers wrote:

      This looked strange to me, and I had expected, that the sharedfolder entry has to be deleted manually first. Otherwise there would be an orphaned reference in the sharedfolder entry to the mntent, wouldn't it. Therefore I asked to have a look again, if you really meant the mntent entry.

      I hope this clarifies my question and my mentioning of "one level of hierarchy missing". By that I meant that I expected, down the hierarchy, before the mntent entry is deleted, the sharedfolder entry has to be deleted.
      The orphaned sharedfolder entry to mntent doesn't hurt anything. The orphaned mntent entry will cause an fstab entry to written and potentially cause the system not to boot. Either way, I remove both entries at the same edit time.

      If you make a backup of config.xml before trying these things, there is very little risk. Sorry for not being clear on my explanation.

      buers wrote:

      Sure. I did not want that drive to fail, however. And I guess it happens to people now and then.
      Yes, I know that. I didn't say you wanted the drive to fail. I was just telling that it is hard to write code to do the right thing when the failure is very unexpected leaving the system in a weird state. As flmaxey found, normally it works. I wouldn't waste your time trying to figure out why it didn't work on your system.

      buers wrote:

      lmaxey obviously had killed the last disk he added. My died disk probably was not the last one I added (although I cannot be totally sure of that). Also I had ntfs. And I was using the root of the filesystem for sharing (which sometimes is not considered best practice).
      Neither of these caused the issue. ntfs and the last disk are treated exactly the same as the other disks.

      buers wrote:

      I saw something like "sharedfolders-elements.mount" and wrongly interpreted this as: hmm, here the elements (?) needed for shared folders are mounted (?).
      Every sharedfolder gets a bind mount to /sharedfolders/[SHAREDFOLDER_NAME]. When you drive failed, this bind mount was still around causing an issue because it depended on the failed drive being mounted.
      omv 4.1.14 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.13
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • ryecoaaron wrote:

      Either way, I remove both entries at the same edit time.
      I started by removing the sharedfolder entry of that dead drive only. After that I could remove all other traces to the dead drive. So problem solved, one could think. It got even more puzzling, however.

      But, when I tried to add another drive, adding a new shared folder did fail again. With exactly the same error message from the start of this thread. My problem seemed to have to do with the dead drive. But it really had nothing to do with it, only the deconfiguration of the drive triggered the error. Anyway, I found it out now …

      While my internal drives have shared folders, that really are folders below /, for external drives (that earlier were connected to Windows computers and filled with data there) I wanted / to be shared. In OMV2 or OMV3 (can't remember), it did not work to use "/" inside the shared folder configuration dialog. (It is called "reldirpath" inside config.xml). I vaguely remember, that I had analysed the problem at that time, and found out that the reldirpath was pasted to the disk, and this yielded in an error because of double "//". Well, I used "./" instead, which worked fine.

      After upgrading to OMV4, it still seemed to work fine. File sharing and other functionality was there. But that mounting to /sharedfolder does not work (and for my usage seemed not to interfere with normal functionality for those old shares). I found out, by editing /etc/systemd/system/sharedfolders-xxxx.mount files and using systemctl command.

      With OMV4, using "/" as a shared folder seems to work. I changed accordingly and now everything seems fine again.

      This problem was tricky!

      Thanks everybody for their hints!

      I wonder one last thing: is this /sharedfolder/xxx structure needed for any functionality?
      Can it even be prevented. When I use "find / xxxxx", I see all found objects twice, once in the /srv hierarchy and once under /sharedfolder.
      OMV 4.1.13-1 (typically everything up to date), only plugin: flash memory; HP Microserver, 4 internal ext4 HDDs, SSD for OS, SD-Card for booting (can't boot on SSD with 4 HDD used …), external USB3 HDDs (ext4 + NTFS)
    • buers wrote:

      s this /sharedfolder/xxx structure needed for any functionality?
      Most people who use the command line or docker like it since they path is easy to remember.

      buers wrote:

      Can it even be prevented. When I use "find / xxxxx", I see all found objects twice, once in the /srv hierarchy and once under /sharedfolder.
      Nope. The mount in /srv is the actual filesystem mount. The mount in /sharedfolder is a bind mount of just the sharedfolder's folder to the easy to remember path.

      One more thing... After removing a sharedfolder entry and filesystem entry in config.xml, you should execute to cleanup fstab and the sharedfolder bind mount units:
      omv-mkconf fstab
      omv-mkconf systemd
      omv 4.1.14 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.13
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • ryecoaaron wrote:

      One more thing... After removing a sharedfolder entry and filesystem entry in config.xml, you should execute to cleanup fstab and the sharedfolder bind mount units:
      omv-mkconf fstab
      I had checked /etc/fstab, and everything looks ok. I did not change anything else besides sharedfolder in config.xml.


      ryecoaaron wrote:

      omv-mkconf systemd
      Did this. Before doing so, I saved the whole /etc/systemd folder, just out of curiosity to be able to have a look at what has been changed. Actually nothing changed after executing the command. The shared folder of the died disk from this discussion was called "Seagate". In /etc/systemd/system, the "sharedfolders-Seagate.mount" file was already missing. But there were still symbolic links inside /etc/systemd/system/local-fs.target.wants/

      Source Code

      1. lrwxrwxrwx 1 root root 47 Nov 11 15:30 sharedfolders-Seagate.mount -> /etc/systemd/system/sharedfolders-Seagate.mount

      ovm-mkconf systemd did not remove that link (which does not have a target anymore). I will remove it ...

      BTW. There is another link without target inside /etc/systemd/system/multi-user.target.wants/

      Source Code

      1. lrwxrwxrwx 1 root root 36 Nov 12 2017 /etc/systemd/system/multi-user.target.wants/php5-fpm.service -> /lib/systemd/system/php5-fpm.service

      A leftover from OMV4 upgrade?

      And a final interesting remark, that might be useful to more readers.


      ryecoaaron wrote:

      If you make a backup of config.xml before trying these things, there is very little risk.

      I did so (and would have done anyway). However, after cp config.xml config.xml.save inside the same directory, OMV will delete the .save file after doing a configuration change and applying it! This certainly was a surprise to me. (I had another copy elsewhere - which I didn't need anyway)-
      OMV 4.1.13-1 (typically everything up to date), only plugin: flash memory; HP Microserver, 4 internal ext4 HDDs, SSD for OS, SD-Card for booting (can't boot on SSD with 4 HDD used …), external USB3 HDDs (ext4 + NTFS)
    • buers wrote:

      A leftover from OMV4 upgrade?
      Yep. The php-fpm package must not clean it up but it really shouldn't cause any problem. If a service doesn't exist that multi-user "wants", it ignores it.
      omv 4.1.14 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.13
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • Users Online 2

      2 Guests

    • Tags