issues with shared folders' device id listed as n/a

  • TLDR & the issue: physically swapped a 1Tb hard drive (label data3) in my machine running omv for a 4Tb (label data4). ever since getting tons of errors in web gui about how it cant find data3 and was repeatedly unable to delete data3 as a filesystem even tho it was unmounted and not connected. as part of trying to resolve that issue, i deleted my unionFS data pool (that all my currently referenced shared folders point to) and am unable to add/edit/delete any shared folders to resolve the issue, even after making shared folders unreferenced.

    i suspect i have solved my original issue of my machine yelling at me that it cant find disk-by-label/data3 by editing the config.xml file; additionally i have been successful in deleteing the data3 file system in the GUI, but I'm still having lots of issues with my shared folders' devices' showing up as "n/a"

    any pointers or things to check next would be greatly appreciated!

    also - is there a way to change the device of a shared folder in the config.xml directly? i tried to do so but either missed something or the config doesn't actually do what i had surmised.

    the following are what this machine has as far as drives:

    data3 = 1Tb disk physically swapped with data4
    data4 = new 4Tb disk physically swapped with data3
    dataPool = original unionFS data pool deleted as part of troubleshooting below.
    hot_tub1 = unionFS data pool recreated in troubleshooting below

    all shared folders are pointed to the *now deleted* dataPool "device"

    troubleshooting done:

    > file system shows a disk-by-label that is unable to be deleted.
    > verified that no shared folders were using it
    > restarted the machine
    > tried to delete dataPool, the original unionfs, that i had previously edited from data3 to data4
    > now getting errors trying to build any new unionfs

    > uninstalled & reinstalled unionFS, still getting the same error
    > also had installed reset permissions plugin and verified there nothing in use
    > all of my shared folders show "n/a" under devices

    > removed all four shared folders from apple filing (media, downloads, personal & timemachine-optiplex)
    > went into shared folders, and tried to delete shared folder (NOT shared + content)
    > was able to click thru the gui window to do so, but when clicking apply get this error:

    > one forum post indicated they fixed it by editing /etc/openmediavault/config.xml
    > found a section listing disks by UUID
    > found this section referencing disk-by-label


    > deleted this in config.xml after making backup config.xml.bak
    > web interface errored and had me sign in again
    > after signing back in Storage > File Systems > Devices still was listing /dev/disk/by-label/data3
    > deleted it again, applied change successfully!
    > went into unionFS and tried to add a new pool (hot_tub1) with data1, data2, and data4 - applied successfully!!
    > shared folders dont look like they will let me edit location

  • continuing since original post was too verbose:

    > possibly thru config.xml too?
    > looking under the "shares" section of the config.xml appears to be a <mntentref>5a499066-8eac-4b77-8bda-1ae3e04bb31a</mntentref>
    > this looks like it references the /srv/ location

    root@theLibrary:/# ls /srv/
    63bc36da-cd70-4f55-a65e-e2f961f8c6f1 dev-disk-by-label-data2 dev-disk-by-label-parity1 ftp
    c88db91e-1e48-4eab-910d-65965fc98d43 dev-disk-by-label-data4 dev-disk-by-label-tera
    dev-disk-by-label-data1 dev-disk-by-label-disk1 f17aba77-84cb-444e-81d0-8646a71b1085

    > but which of these is the correct data pool? maybe config.xml will tell us
    > looking near the end under what appears to be the plugins section found

    > hazarding a guess that 63bc36da-cd70-4f55-a65e-e2f961f8c6f1 is the main identity of hot_tub1 (my newly data pool name)
    > verified 63bc36da is indeed hot_tub1 in web gui
    > only going change this location ID for the unreferenced shared folder first as a test
    > not sure how would behave for mounted ones?
    > changing the config file for shared folder "downloads"


    > also added a comment in the line above mntentref
    > reloaded web gui - comment showing up but device still n/a
    > another check of the config.xml does still show the mntentref for downloads is 63bc36da
    > might have to delete and readd the folder via web gui
    > when i click edit or delete on the shared folder in Access Rights Management > Shared Folders it errors as follow

    > so it seems whatever is going on, unionfilesystem doesnt play nice with c88db91e-1e48-4eab-910d-65965fc98d43
    > c88db91e is not found anywhere in config.xml
    > via SSH shell, using blkid to check for c88db91e there - no dice
    > tried to delete shared folder "downloads" anyway despite errors - clicking apply generates this

    > rebooting the system, still getting the error directly above
    > error occurs when trying to add, edit, or remove a shared folder

    Thank you in advance for any feedback or advice!!!

  • another update: after reading this thread stating not to use /sharedfolder/blah in any docker setups - i have edited all my containers to point to /srv/63bc36da-cd70-4f55-a65e-e2f961f8c6f1/ instead.

    however still getting this error when trying to add/edit/delete any shared folders. besides docker, AFP & SMB are the only other services that i have configured to use shared folders

  • <mntentref>5a499066-8eac-4b77-8bda-1ae3e04bb31a</mntentref>

    This could be way beyond my pay grade :) but the above is incorrect, this is from my own .xml for unionfs
    This is the sharedfolder reference
    sharedfoldermnt .jpg

    hopefully this will clarify that part.

    Whilst you were correct to make a backup of the xml file this

    OMV\Config\DatabaseException: Failed to execute XPath query '//system/fstab/mntent[uuid='5a499066-8eac-4b77-8bda-1ae3e04bb31a']'. in /usr/share/php/openmediavault/config/

    would suggest that fstab requires updating, which if you make changes like you have I believe it does. So change the config then run omv-mkconf fstab you may also need to reboot for the change to take effect.

  • This could be way beyond my pay grade :) but the above is incorrect, this is from my own .xml for unionfsunionfs.jpg
    This is the sharedfolder reference
    sharedfoldermnt .jpg

    hopefully this will clarify that part.

    this worked a treat - good catch on this! it seems that i had wrongly mistaken that the shared folders reference the uuid of the unionFS, when they do definitely reference the unionFS's self-mntent.

    for completeness and anyone searching this thread later, here is what i did:

    > the sharedfolder mntent requires the self-mntent listed in the unionFS section NOT the mntent (which is what i had done)


    > i had previously changed the shared folder's mntent to 63bc6da when it by this logic it needs to be 7c51dcd4
    > root@theLibrary:/etc/openmediavault# cp config.xml /sharedfolders/personal/config.xml.bak
    > editing the "downloads" folder once more to the unionFS self-mntent, changed


    > reloaded the web gui and it worked!!!! "downloads" shared folder now shows to reference "hot_tub1"
    > doing the same for the other unreferenced folder "timemachine-optiplex" - success!
    > deleted SMB and NFS references to shared folders "media" & "personal" and repeating the process
    > typoed something because the web gui gives an error 709 (or 907) on every page
    > rolled back to prior backup config.xml.bak and redid "downloads & timemachine-optiplex"
    > again, removed SMB & NFS references so "media" & "personal" are now unreferenced
    > root@theLibrary:/etc/openmediavault# cp config.xml /sharedfolders/personal/config.xml.bak2
    > corrected all shared folders and now all reference the current unionFS datapool
    > further tests reveal zero errors when adding, editing, and removing shared folders

    whew! on the upside, i've learned quite a bit how omv is setup via the config.xml file.

    thank you thank you thank you @geaves for helping me out! merely correcting my prior mistake in the config.xml was all that was needed - i didn't need to run omv-mkconf fstab nor reboot for things to start working correctly again.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!