Shared Folders all empty after reboot

    • Resolved
    • OMV 4.x
    • Shared Folders all empty after reboot

      I did see a similar thread but it never seemed to be resolved.

      Every time I reboot now, all the "Shared Folders" appear empty.

      This is a setup I've been fooling with for a few months, with the intention of putting it into production. It's been rebooted numerous times without issue, but as of today, after updating to 4.1.24-1.and restarting, the shared folders no longer seem to have any files in them on each boot. The files still exist but not when accessed via the sharedfolders path.

      I can't see them if I SSH in as root.
      None of the services can see them - e.g VirtualBox, HDHomeRun.
      I CAN see the files via Samba, but looking at the smb.conf file it appears that the SMB share points directly to the physical path, not the sharedfolders path.

      I have two ZFS mirrors for storage, i can see all the data and files if I go to the pool directly.

      I can "fix" the issue temporarily by adding a new shared folder and applying the config which I assume triggers a process to update the config files.

      Not sure where to start - where is the mapping between the Shared Folder and the physical path defined?

      The post was edited 2 times, last by Griffo ().

    • Further - is the way that OMV works by writing these as mount-points in fstab?
      (sorry if my terminology is all mixed up, i'm new to Linux)

      I can see the shares defined in the /etc/openmediavault/config.xml

      for example

      Source Code

      1. <sharedfolder>
      2. <uuid>d2dbd58d-b647-43c8-a597-638be027c1f8</uuid>
      3. <name>Recording</name>
      4. <comment></comment>
      5. <mntentref>bf934160-b23d-4533-8d78-54094d935a1e</mntentref>
      6. <reldirpath>Recording/</reldirpath>
      7. <privileges>
      8. <privilege>
      9. <type>user</type>
      10. <name>administrator</name>
      11. <perms>7</perms>
      12. </privilege>
      13. <privilege>
      14. <type>user</type>
      15. <name>mceuser</name>
      16. <perms>7</perms>
      17. </privilege>
      18. </privileges>
      19. </sharedfolder>
      Display All



      but I don't see corresponding entries in the etc/fstab

      Source Code

      1. root@lusus:/sharedfolders/HDHomeRun# cat /etc/fstab
      2. # /etc/fstab: static file system information.
      3. #
      4. # Use 'blkid' to print the universally unique identifier for a
      5. # device; this may be used with UUID= as a more robust way to name devices
      6. # that works even if disks are added and removed. See fstab(5).
      7. #
      8. # <file system> <mount point> <type> <options> <dump> <pass>
      9. # / was on /dev/sde1 during installation
      10. UUID=d9bd9a8c-e5f1-4964-94a7-8b913d515593 / ext4 errors=remount-ro 0 1
      11. # swap was on /dev/sde5 during installation
      12. UUID=26085b09-525c-4f73-ad73-6eabbb7abebc none swap sw 0 0
      13. tmpfs /tmp tmpfs defaults 0 0
      14. # >>> [openmediavault]
      15. # <<< [openmediavault]
      Display All
    • Griffo wrote:

      but I don't see corresponding entries in the etc/fstab
      They are individual systemd mount unit files. This has probably to do with a recent commit github.com/openmediavault/open…1997fe7848945203259e15c6b to fix plenty of issues regarding this folders, with pooling fs.

      The commit shows the correct approach attempt to mount those units after al local-fs and remote-fs targets have been reached, but problem i see is that you are using probably those mounts to your services, so i assume your services are starting before these units.

      It hasn't been documented properly but in several commits logs from @votdev and comments here he has insisted that these path's should not be used for services. They should be used by scripts, sftp access, etc. but not services.

      I think you know what to do from here, either change the services configs, or use a pool of symlinks if you don't like typing the long paths
      New wiki
      chat support at #openmediavault@freenode IRC | Spanish & English | GMT+10
      telegram.me/openmediavault broadcast channel
      openmediavault discord server
    • Thanks. I appreciate the response.

      I've actually un-installed all plugins (apart from ZFS) to remove the possibility that one of them was interfering by starting earlier than the mount. I've also uninstalled the one LInux service (HDHomeRun) that i've installed.
      Unfortunately the problem remains.

      I'm happy to use the actual path, but many of the plugins like VirtualBox only allow you to select the "Shared Folder" path so it needs to survive reboots.

      I don't actually know where to go to next.
    • OK it only seems to affect folders on ZFS volumes. I created some on an USB key with EXT4 and they survive a reboot.

      I guess the change has implemented a timing issue (even though the .mount file contains the dependancies)

      Running the following commands restores the shares which I assume means that all the config is OK

      Source Code

      1. systemctl daemon-reload
      2. systemctl restart local-fs.target

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

    • Can you please verify if the issue is fixed when we re-add the After=zfs-mount.service?
      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
    • Thx, good to know. Will add the line again in the next version.
      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
    • Fixed in openmediavault 4.1.25, see github.com/openmediavault/open…c51fed49a8759336e247cf2cc.
      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
    • thermo wrote:

      Adding After=zfs-mount.service didn't fix the problems I encountered. However, I do not use zfs but ext4.
      I cam confirm that this is the case, the fix initially was this however removing zfs-mount is not a solution, the solution is simply not to use /sharedfolders but to use /srv which is the absolute path especially in docker or any plugin that requires you to point to a share.
      Raid is not a backup! Would you go skydiving without a parachute?
    • Installed the update to 4.1.25-1 today. Same strange behaviour. After restart and decryption of the luks encrypted storage all shares under /sharedfolders/<share> are empty. Data is untouched and everything is still mounted under /srv/dev[...]/. SMB does work.

      If I add another "test" share shares under /sharedfolders/<share> arn't empty anymore.

      SFTP doest not work after restart. All shares unter /sftp/<user>/<share> are empty. Restart of the SFTP plug-in also solves this problem.

      Summarized workaround, after Restart: 1) decrypt storage 2) create "test" share and delete this share 3) disable SFTP 4) enable SFTP.