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?

  • 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




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

    • Offizieller Beitrag

    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 https://github.com/openmediava…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

  • 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


    Code
    systemctl daemon-reload
    systemctl restart local-fs.target
    • Offizieller Beitrag

    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.

  • 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.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!