It’s not sufficient to just check fstab because someone might be using a native systemd mount unit. To parse those correctly from a bash script is a lot of work.
You would need to check for unit files like: /lib/systemd/system/.mount, /etc/systemd/system/.mount and parse their contents to find what paths are used there as well.
And to be fully correct you would also have to check for systemd drop ins which would be like: /etc/systemd/system/.d/.conf.
Doing this properly from a bash script is a lot of work and likely to be fragile so I still maintain the position that we are simply better off not to manually mount things in /media and leave that for the automounter, with a readme file in /media to explain to users that they should be using /mnt.
I’ve already described a workaround for those that insist on mounting in /media anyway - create any file in your mount point when unmounted and it will not be automatically removed…
Thanks for this @DBMandrake, is one preferred over the other? and why exactly?
Thank you also for the information on /mnt being the preferred mount point for osmc, I too have mounted to /media in the past (using /etc/fstab) out of ignorance but will instead mount to /mnt when I make the move from A4 to RC in the next couple of days.
Yes we get automatic notifications for pull requests and github issues.
It’s unlikely to be accepted in it’s current form though because it adds more complexity (read: things to go wrong) and only partly solves the “problem”.
It’s also a very low priority issue compared to the many other bug fixes and improvements that we are working on and trying to get finished before final release.
So at the moment the README file is likely to remain the solution to this.
I think limiting the mount point locations is basically a cop out to not setting up the OS correctly. Sorry to put it that way and I mean it with the utmost respect. I don’t assemble OSs and the work you guys do is mind blowing even for someone like me with plenty of experience in other facets of computing.
That said it still feels like a cheap “won’t fix”. I’ve been using /media as mount points for a long time and no other linux variant has had any issues with it. So why start with OSMC?
The ultimate solution is to have automount clean up after itself. My question is why is this an issue with OSMC but not with say Ubuntu or Debian?
As for your work around @DBMandrake I don’t think that works because when you go to remount the device the mount will fail because the mount point isn’t empty.
Again hopefully so this isn’t misconstrued as an “I demand and therefore must be heard!!!” this IS a low priority. I can easily work around this by mounting in userland instead of fstab and writing wrappers to ensure my mount points are there. I’m trying to help build a better (more flexible) product.
When I have time I will do more digging on this. TV boxes are very low on the priority list…
so If I want to wait the hdd to gets fully mounted I should add
Requires=udisks-glue.service to my service?
I tried use this but didn’t worked:
RequiresMountsFor=/media/HDD
RequiresMountsFor=
Takes a space-separated list of absolute paths. Automatically adds dependencies of type Requires= and After= for all mount units required to access the specified path.
Mount points marked with noauto are not mounted automatically and will be ignored for the purposes of this option. If such a mount should be a requirement for this unit, direct dependencies on the mount units may be added (Requires= and After= or some other combination). systemd.unit
Sorry, don’t know the answer to your question, or I would reply.
Requires=udisks-glue.service will not work because that does not set up service ordering but rather dependencies. What you probably intend is After=udisks-glue.service but this will also not work because it simply waits until the udisk-glue service has started, but that does not mean any drives have been mounted yet.
I’m not sure what the correct way is wait for a certain mount point to mount in a system service and don’t have the time to research it I’m afraid.
I thought I’d draw your attention to this - apparently we are not the only distribution to clear unused mounts in /media, OpenSuse 12.1 and later mount /media as tmpfs (presumably, from the description) which means its contents is entirely wiped every boot:
BUT after RESTART, all folders inside /media are ERASED.
If I try to mount again, dolphin says “mounting point doesnt exist”
and I should create again /dvd and /usb inside /media.
That’s the reason it will not work.
This is an intentional feature of 12.1, it is documented (or it should, I
wrote a bugzilla requesting it be documented).
/media is a directory created in RAM, not hard disk. It disappears on any
reset. If you want mounts there via fstab, do not use them. Instead create
them in /mnt. If you insist on using /media, it is up to you to create the
mount points with appropriate permissions on every reboot.
Hey @DBMandrake. Thanks for the follow up. I actually took another swing at this last week but didn’t get anywhere and I’m close to admitting defeat, as it seems that with systemd this becomes a much larger battle.
Guess I’m going to have to get used to the idea that everything should be moved to /mnt instead of /media.
