Wrong boot time ordering leads to file system confusion

[mathieubolla]

Hi,

I've encountered the following issue:

Context

OVM 5.6.21-1 setup on a virtual machine in a large Proxmox node

Small boot disk (8Gb on /dev/sda)

Large data disk (8Tb on /dev/vda)

The boot is obviously mounted on /.

The data disk is mounted on /src/dev-disk-by-label-rack0bay3.

This filesystem is split in multiple shares, each mounted on /export/folderA, /export/folderB, etc. using btrfs subvolumes.

All the config was done using OMV web interface, there is no command line trick.

Use case

Some laptops are syncing large directories. This is done by mounting nfs shares and running rsync from their local drive to the nfs mount point.

Unexpected behavior

During a power outage, the OMV server was shutdown properly (using ACPI shutdown)

The laptops were still trying to send data as they are on battery power

When power came back, OMV restarted

The nfs shares came back before the large drive was mounted on /export/folder*

The clients wrote files to the nfs mounts, which ended up on /export/folderA (not a mount on a sub volume, directly on "/" root filesystem)

Then the big drive got mounted

The clients wrote other files to /export/folderA (this time, the mounted sub volume, hiding the directory on root filesystem)

OMV was barely usable after that, with root filesystem full and unable to delete data in the unexpected folders (masked by the mount points) Has to reboot in single user mode to delete extraneous data from root filesystem.

Expected behavior

NFS should not be up & running before all drives are mounted at boot to prevent writing to folders on root fs instead of mount points to attached drives

Conclusion

Let me know if the issue is clear enough (i'm not that familiar with linux filesystems, trying to use the right words...) and if you need anything else to help spot the issue.

It looks a bit linked to https://github.com/openmediavault/openmediavault/issues/871 or https://github.com/openmediavault/openmediavault/issues/114 but I'm unsure (yes, I did research open issues prior to opening one)

Thanks a lot,

Mathieu

[votdev]

OMV currently has absolutely no influence on the order in which the file systems are mounted since this task is done by the init system. With the /etc/fstab approach it is not possible to define dependencies; this is only possible when switching to systemd mount-units files. This switch has not been done till now because this has dramatic consequences in how file systems are mounted and unmounted. The usual CLI commands can not be used then anymore, everything must be done via systemctl which breaks the standard way admins normally handle mounts.

[dsm1212]

Unmount the disk and then use "chattr +i mountpoint". This makes the mountpoint itself unwritable. You can still mount to it and the mounted disk is usable.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days.