Binding a drive that is mounted to /run on boot

[Bosnia]

Hi,

First of all, apologies if this is in the wrong section. I’m not sure where to put drive-related topics.

I’ve been trying to bind a a folder from a drive that gets mounted to /run on boot. To bind it, I created a systemd service that executes mount --bind /run/media/user/Space/Movies /mnt/Movies. I also specified that the service should be run after the /run/media/user/Space drive gets mounted by adding both After=run-media-user-Space.mount and Requires=run-media-user-Space.mount to the service. Unfortunately when I boot my computer, I get an error that states:

mount: /mnt/Movies: special device /run/media/user/Space/Movies does not exist.

which I’m guessing is due to the mounting process for Space not completing before the bind service runs. If I run the service after the computer boots, the folder gets bound to /mnt/Movies without a problem.

Is there a special parameter I need to add to ensure that a drive is properly mounted before the binding service can run?

Thanks.

[stephane]

[root tip] Use systemd to mount ANY device

Difficulty: ★☆☆☆☆ Disk device recognition Manjaro uses udev (see Arch Wiki) to load devices at boot time. The loading of devices is arbitrary and therefore you cannot predict which device will be available at a given path. But static device names do exist and you can assign specific locations to your device and thus ensure e.g. scripts will work as expected. What to learn Overview of system mount units Structure and Content of a mount unit Mount at boot (immediate mount) Mount on demand (mou…

[Bosnia]

Thanks for the post. It seems like most of the content is about mounting but are there similar methods for performing binding mounts like this?

[Aragorn]

Not a direct reply to your question, but the post below contains information regarding where and how to statically mount additional drives, so it may help you on your way.

Shared HDD (win e Manjaro) error read-only file system

NTFS is not a POSIX-compatible filesystem and does not store POSIX file ownership information or permissions. This means that the ownership and permissions must be emulated by the Linux kernel upon mounting the filesystem into the virtual filesystem layer. Given that the filesystem is mounted somewhere under the /run hierarchy ─ which only exists in memory while the system is up and running, because /run itself is mounted as a tmpfs ─ you are obviously relying on the automagic from the udisks2 …

[Bosnia]

Thanks for the link. I’ve been trying to find a way to do this without statically mounting the original drives because I have a lot of programs pointing to the current location. Looks like I might just have to bite the bullet and do it though.