Error when deleting shared folder

    • OMV 4.x
    • Resolved
    • macom wrote:

      Ok, but does it also work like this if the physical drive does not exist any more.
      Usually but I haven't tried it lately. Worst case, follow what I recommended and if you can't delete the missing entry in the filesystems tab, THEN delete the mntent entry in config.xml. You should always be able to delete the shared folders from services and delete the shared folder itself.
      omv 4.1.15 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!
    • Buers wrote:

      flmaxey: "Note that deconfiguring a drive must be done in the same order that it was configured, but in reverse order. "

      Well, my drive died. It seems that OMV needs a working drive, to properly remove it? Of course, I may not have understood, how to do it.. When I try to remove the file system of the dead drive from shared folders, I get the errors described above. OMV shows me, that there are no references left to the shared folder. (I had removed CIFS/SMB references before).
      Even with a missing drive, "de"configuring works with EXT4.
      ________________________________________________________

      I just ran through the entire process in a VM:

      1. Install a new drive
      2. Create a file system. (EXT4)
      3. Mount the file system
      4. Create a shared folder (Music)
      5. Create an Rsync Job that references the shared folder.
      (Run the Rsync job to populate the shared folder with files)
      6. Share the folder to the network with SMB/CIF
      ___________________________________________________________________________

      I have the "Reset Perm's" plugin installed which provides the Shared Folder in Use tab in Access Rights Management, Shared Folders. (In the following: Ignore Music_R_OMV - that's a file system, on another server, added by Remote Mount .)

      So, on the local Data drive;
      - I have "Music", added as a shared folder.
      - I referenced the shared folder, music, with an Rsync job.
      - I put the shared folder on the network with SMB/CIF





      I then removed the data drive - as in it's completely gone. Storage, File Systems shows it as "Missing".
      ___________________________________________________________________________

      6. I deleted the SMB/CIF share - music.
      5. I deleted the Rsync Job that references the music folder
      4. I deleted the shared folder Music
      3. I unmounted the file system (EXT4)
      2. I deleted the file system.
      1. The drive is already gone.

      Using the screen above, at step 4, you'd need to remove all services, (Rsync, SMB, etc.) from each of your shared folders, then delete the shared folders themselves. Check Shared Folder in Use to insure all has been removed.

      After that, you should look for any configured SMART TESTS set for the physical drive and SMART Monitoring. Delete those as well. After than, delete the file system. If the drive is still in the machine, in Physical drives, wipe it or physically remove (if you haven't already).

      Video Guides :!: New User Guide :!: Docker Guides :!: Pi-hole in Docker
      Good backup takes the "drama" out of computing.
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      OMV 4.1.13, Intel Server SC5650HCBRP, 32GB ECC, 16GB USB boot, UnionFS+SNAPRAID
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk

      The post was edited 3 times, last by flmaxey: edits ().

    • I understand this is the process it is supposed to be.

      But as I understood the point of this thread is, that the drive is not there any more. As far as I understand the process is working like this only to a certain point in case the drive is not there any more.


      buers wrote:

      Well, my drive died. It seems that OMV needs a working drive, to properly remove it? Of course, I may not have understood, how to do it.. When I try to remove the file system of the dead drive from shared folders, I get the errors described above. OMV shows me, that there are no references left to the shared folder. (I had removed CIFS/SMB references before).
      Odroid HC2 - armbian - Seagate ST4000DM004 - OMV4.x
      Asrock Q1900DC-ITX - 16GB - 2x Seagate ST3000VN000 - Intenso SSD 120GB - OMV4.x
      :!: Backup - Solutions to common problems - OMV setup videos - OMV4 Documentation - user guide :!:

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

    • As noted, in the above exercise, the drive was not there either. (As in deleted, gone, and missing on the file system page.)

      The drive doesn't have to exist to delete the file system associated with it. However, to delete the file system, references to the drive can not exist.
      ______________________________________________



      Even with "Status" Missing, if "Referenced" is No; the Delete button should be available. If the Delete button is not available, that's not normal behavior. Perhaps there's a fix or patch for this ( @ryecoaaron 's advice above) but, as a matter of preference, I'd consider rebuilding to insure the install is clean and clear of other potential issues.

      Video Guides :!: New User Guide :!: Docker Guides :!: Pi-hole in Docker
      Good backup takes the "drama" out of computing.
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      OMV 4.1.13, Intel Server SC5650HCBRP, 32GB ECC, 16GB USB boot, UnionFS+SNAPRAID
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
    • macom wrote:

      flmaxey wrote:

      As noted, in the above exercise, the drive was not there either.
      Missed that, sorry.
      It's all good! :D

      Let's hope that @buers finds a reference to delete.

      Video Guides :!: New User Guide :!: Docker Guides :!: Pi-hole in Docker
      Good backup takes the "drama" out of computing.
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      OMV 4.1.13, Intel Server SC5650HCBRP, 32GB ECC, 16GB USB boot, UnionFS+SNAPRAID
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
    • I think, I have written it before: I am not aware of any references left. Under services I don't find any reference. I also added a screenshot post #16, that seems to show, that there are no references left.

      BTW. If there were any references left, one could hope for a more helpful error message than the one I got and I have shown in post #1-
      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)
    • ryecoaaron wrote:

      You should remove the shared folder from each service using it.
      I did. Or perhaps I do misunderstand, what you mean. Maybe you can have a look at the screenshot in post #16.

      ryecoaaron wrote:

      Then delete the shared folder.
      The I get the error message from the first post of this thread.

      Did you have a look at the error message from post #1? It seems to complain, that the drive is dead. Unfortunately it really died ...
      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:

      I did. Or perhaps I do misunderstand, what you mean. Maybe you can have a look at the screenshot in post #16.
      I wasn't telling you what you needed to do. I was answering macom's general question about removing things in this situation since he tagged me (I didn't read the whole thread). Your screenshot says it isn't referenced. So, no shared folders should need to be deleted. If the delete button in the filesystems tab doesn't work, you need to remove the mntent entry manually.
      omv 4.1.15 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!
    • flmaxey wrote:

      I then removed the data drive - as in it's completely gone. Storage, File Systems shows it as "Missing".
      ___________________________________________________________________________

      6. I deleted the SMB/CIF share - music.
      5. I deleted the Rsync Job that references the music folder
      4. I deleted the shared folder Music
      3. I unmounted the file system (EXT4)
      2. I deleted the file system.
      1. The drive is already gone.
      Thanks for your effort. I did more or less the same. I had no rsync job, only smb. At your 4., I got the error message from post #1.


      flmaxey wrote:

      Check Shared Folder in Use
      Do you mean, like in my screenshot of post #16 or anything else?
      I am not able to find that "Shared Folder in Use" Tab from your screenshot easily.
      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)
    • ryecoaaron wrote:

      So, no shared folders should need to be deleted. If the delete button in the filesystems tab doesn't work, you need to remove the mntent entry manually.
      Hmm, can you - or anybody else - please elaborate.

      I guess the mntent entry is the following:

      [/code]<mntent>
      <uuid>3743292e-fa2d-49d7-a035-161469f18961</uuid>
      <fsname>/dev/disk/by-id/ata-ST4000DM000-1F2168_Z302YX7G-part2</fsname>
      <dir>/srv/dev-disk-by-id-ata-ST4000DM000-1F2168_Z302YX7G-part2</dir>
      <type>ntfs</type>
      <opts>defaults,nofail</opts>
      <freq>0</freq>
      <passno>2</passno>
      <hidden>0</hidden>
      </mntent>
      [/code]
      But, when I delete this, there would be a stale sharedfolder entry be left

      Source Code

      1. <sharedfolder>
      2. <uuid>bf729f44-bbee-4615-bc34-327fc7b9642a</uuid>
      3. <name>Seagate</name>
      4. <comment/>
      5. <mntentref>3743292e-fa2d-49d7-a035-161469f18961</mntentref>
      6. <reldirpath>./</reldirpath>
      7. ...
      8. </sharedfolder>

      So, to me it looks wrong, to delete the mntent. After all, I was not Abel to delete/remove the shared folder.

      Anyway: how to delete it? Just edit config.xml with vi? I would expect, that services or something else must be stopped or restarted or something similar.
      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:

      But, when I delete this, there would be a stale sharedfolder entry be left
      When the filesystem says it isn't referenced, there *shouldn't* be any sharedfolders pointing to it. Your system is in a weird state if that is the case.

      buers wrote:

      So, to me it looks wrong, to delete the mntent. After all, I was not Abel to delete/remove the shared folder.
      If there is a sharedfolder pointing at it, delete the mntent entry and sharedfolder entry from config.xml.

      buers wrote:

      Anyway: how to delete it? Just edit config.xml with vi? I would expect, that services or something else must be stopped or restarted or something similar.
      Yes, just edit it with whatever editor you like. Unless the sharedfolder is referenced by a service, you don't need to restart any services. If the sharedfolder is referenced by services/plugins, you would need to remove those first. I would execute omv-mkconf fstab after removing the mntent entry. Make a backup of config.xml before you edit anything. If you do something wrong, copy the file back in. And config.xml isn't continually referenced by services. It is just used to populate the web interface and then used to write config files when told to update them.
      omv 4.1.15 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!
    • flmaxey wrote:

      Even with "Status" Missing, if "Referenced" is No; the Delete button should be available.
      The Delete button is available. When I hit it, I have the choice between "Shared folder" and "Shared folder including contents" [translations from my German OMV UI to English are mine and most probably are not exactly the same, that is shown in the English UI]. I choose "Shared folder". I am asked for a confirmation "Do you really want …" I answer yes. Then I am asked for the typical OMV confirmation: "Configuration was changed … Apply or Cancel". When I apply, I get the error from post #1- Only way I found to proceed, is to cancel.
      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)
    • While I'll concede that there may be a real problem - it only takes 1 reference of some kind to prevent deleting the file system and, after that, the drive. Since that means finding the reference(s) or a rebuild, it doesn't hurt to ask and one reference is easy to miss.
      ______________________________________________________

      First, go to System, Plugins and find the openmediavault-resetperms plugin. Install it.

      After the plugin is installed, then you'll have the "Shared Folder in Use" tab, as shown in the post above. If you have any services attached to shared folders that are gone, again as shown, you'll have an indication of where to go to find the service and delete it. In the example, there was an Rsync job (requires that the appropriate configured job under Services, Rsync be deleted), a SMB network share (required that the appropriate network share under Services, SMB/CIF be deleted), and finally the shared folder itself.

      (**But,, the shared folder itself, where you got your error, can't be deleted until all services attached to it are gone.**)

      Depending on what you configured on the missing drive, there may be several items to remove.
      _______________________________________________________________

      Beyond the above:

      What file system was the dead drive using?
      If you were using anything that required a plugin, such as ZFS or UnionFS, it might be necessary to delete and reinstall the plugin.

      Also, other plugins like LVM, rsnapshot, disk encryption, etc., can reference a file system and hold it.

      Video Guides :!: New User Guide :!: Docker Guides :!: Pi-hole in Docker
      Good backup takes the "drama" out of computing.
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      OMV 4.1.13, Intel Server SC5650HCBRP, 32GB ECC, 16GB USB boot, UnionFS+SNAPRAID
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
    • ryecoaaron wrote:

      When the filesystem says it isn't referenced, there *shouldn't* be any sharedfolders pointing to it.
      You are certainly the better expert for OMV than me. But anyway, can you please recheck your answer. Seems you were missing one level of reference in the hierarchy in your answer.

      Services (like SMB) do reference shared folders.
      When the Shared folders are not referenced anymore by any services, the Shared folder tab (like in my screenshot) show a "No" under references. Please note, that your sentence starts with "filesystem" while my screenshot (which you where refering to) was about shared folders.

      I removed all Services. After that I expect, that there are still shared folders left in config.xml. But there are no references left to that shared folder. Seems no contradiction to me at all.
      Only removing the Shared folder (as described in detail in post #34) would remove the sharedfolder inside config.xml from my logic. So it is no surprise to me (as opposed to your arguing in #33), that at this time, sharedfolder is still left in config.xml.
      Please correct, where I went wrong.

      Did anybody have a look at the error messages of post #1 and can explain them?
      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)
    • I will have a look at your suggestions later.

      I am really pretty confident, that only services I had configured were SMB (and some time earlier NFS). I had removed both references. My screenshot in #16 shows, that no references are left. Or do I miss anything there?

      flmaxey wrote:

      What file system was the dead drive using?
      It was an external USB drive with NTFS (it worked well for about 2 years before inside OMV).
      Only plugin I am using is flash memory.
      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:

      ryecoaaron wrote:

      When the filesystem says it isn't referenced, there *shouldn't* be any sharedfolders pointing to it.
      You are certainly the better expert for OMV than me. But anyway, can you please recheck your answer. Seems you were missing one level of reference in the hierarchy in your answer.
      @ryecoaaron doesn't miss much and he is the expert in this subject and most others like it - like "Linux" in general. And he's even a good excellent electrician. (I had to edit "good". In addition to Phase Angle Theta and a Power factor of 1, theory stuff, he knows how to wire like an artist. :thumbup: )

      buers wrote:

      Services (like SMB) do reference shared folders.
      When the Shared folders are not referenced anymore by any services, the Shared folder tab (like in my screenshot) show a "No" under references. Please note, that your sentence starts with "filesystem" while my screenshot (which you where refering to) was about shared folders.
      There is a hierarchy involved. (And while it may not apply to you, for others who may read this thread.)

      Physical Drive
      - (Physical drive services like SMART tests and monitoring)
      - (Volume & sub-volume types, if any (LVM, RAID, etc.)
      File system
      - (file system services like encryption)
      Share
      - share only services, if any (like rsnapshot)
      Services (Rsync, SMB)
      __________________________________________________________________________

      NTFS on an external drive - that's a wild card,, and when you say you had an NFS share based on an NTFS drive share.... While I don't use NFS now, I had an experience where an NFS share just wouldn't go away.

      Also, there's your upgrade to consider. Going from OMV 3 to 4, especially if this problem existed in OMV3... Rebuilding, sometimes, makes sense. From a time standpoint alone, a rebuild is better than chasing a phantom problem.

      Here's to hoping that it works out for you but, if it doesn't and you have to rebuild, consider booting on a USB drive and cloning your boot drive. How to do that (a USB boot drive and cloning) is in this guide.

      If you rebuild, I'd unplug your data drive, build your boot drive and when all is updated and healthy, plug in and mount the data drive. The content, in your various folders, will still be there.

      Video Guides :!: New User Guide :!: Docker Guides :!: Pi-hole in Docker
      Good backup takes the "drama" out of computing.
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      OMV 4.1.13, Intel Server SC5650HCBRP, 32GB ECC, 16GB USB boot, UnionFS+SNAPRAID
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk

      The post was edited 1 time, last by flmaxey: edit ().

    • buers wrote:

      But anyway, can you please recheck your answer. Seems you were missing one level of reference in the hierarchy in your answer.
      What level am I missing? Shared folders can be referenced and filesystems can be referenced. You didn't mention a problem removing a shared folder from a service. So, I didn't mention that step.

      buers wrote:

      I removed all Services. After that I expect, that there are still shared folders left in config.xml. But there are no references left to that shared folder. Seems no contradiction to me at all.
      Only removing the Shared folder (as described in detail in post #34) would remove the sharedfolder inside config.xml from my logic. So it is no surprise to me (as opposed to your arguing in #33), that at this time, sharedfolder is still left in config.xml.
      Please correct, where I went wrong.
      I am very confused by what you are asking. When you remove the sharedfolder from services, that process does not delete sharedfolder itself and of course there is still a sharedfolder entry in config.xml. It will only be removed when you delete it. Since your system was running into an error when trying to delete it, I said delete the entry in config.xml. Once all sharedfolders are deleted that reference a filesystem, then you can delete that filesystem. I really don't like when people have to edit config.xml.

      buers wrote:

      Did anybody have a look at the error messages of post #1 and can explain them?
      Yes. The error with the mount unit when trying to delete the sharedfolder is *probably* caused by something still in use or the mount unit failing to mount something that doesn't exist (they don't like missing hardware). Most things in most OSes don't like when hardware is configured and then it disappears.
      omv 4.1.15 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:

      When you remove the sharedfolder from services, that process does not delete sharedfolder itself and of course there is still a sharedfolder entry in config.xml. It will only be removed when you delete it.
      This is also exactly, what I have understood


      ryecoaaron wrote:

      Since your system was running into an error when trying to delete it,
      right, exactly this happened

      ryecoaaron wrote:

      I said delete the entry in config.xml.
      Well, you said some messages ago:

      ryecoaaron wrote:

      you need to remove the mntent entry manually.
      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.

      ryecoaaron wrote:

      Most things in most OSes don't like when hardware is configured and then it disappears.
      Sure. I did not want that drive to fail, however. And I guess it happens to people now and then.

      flmaxey had tried to reproduce the died disk and what I did, and had obviously no problem removing all traces to it. I had problems and still have. So I am starting to wonder, where the difference is. flmaxey 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).

      I also had a look at that error message again, which admittedly confused me. I saw something like "sharedfolders-elements.mount" and wrongly interpreted this as: hmm, here the elements (?) needed for shared folders are mounted (?). Only just now I have understood, that I have another disk (still living and working) that is named Elements.
      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)