Doesn’t mount at boot, but if I issue sudo mount -a it does.
Journalctl grepped for mycloud:
Jun 20 10:59:16 xircon-w6567sz systemd[1]: Mounting /media/mycloud...
Jun 20 10:59:16 xircon-w6567sz systemd[1]: media-mycloud.mount: Mount process exited, code=exited, status=32/n/a
Jun 20 10:59:16 xircon-w6567sz systemd[1]: media-mycloud.mount: Failed with result 'exit-code'.
Jun 20 10:59:16 xircon-w6567sz systemd[1]: Failed to mount /media/mycloud.
Jun 20 13:44:45 xircon-w6567sz kernel: raid6: skip pq benchmark and using algorithm avx2x4
Jun 20 13:44:45 xircon-w6567sz systemd[1]: Condition check resulted in Rebuild Dynamic Linker Cache being skipped.
Jun 20 13:44:45 xircon-w6567sz systemd[1]: Condition check resulted in File System Check on Root Device being skipped.
Jun 20 13:44:45 xircon-w6567sz systemd[1]: Condition check resulted in Repartition Root Disk being skipped.
Jun 20 13:44:45 xircon-w6567sz systemd[1]: Condition check resulted in First Boot Wizard being skipped.
Jun 20 13:44:45 xircon-w6567sz systemd[1]: Condition check resulted in Rebuild Hardware Database being skipped.
Jun 20 13:44:45 xircon-w6567sz systemd[1]: Condition check resulted in Create System Users being skipped.
Jun 20 13:44:46 xircon-w6567sz systemd[1]: Condition check resulted in First Boot Complete being skipped.
Jun 20 13:44:46 xircon-w6567sz systemd[1]: Condition check resulted in Store a System Token in an EFI Variable being skipped.
Jun 20 13:44:46 xircon-w6567sz systemd[1]: Condition check resulted in Commit a transient machine-id on disk being skipped.
Jun 20 13:44:46 xircon-w6567sz systemd[1]: Condition check resulted in Virtual Machine and Container Storage (Compatibility) being skipped.
Jun 20 13:44:48 xircon-w6567sz systemd[1]: Condition check resulted in Rebuild Dynamic Linker Cache being skipped.
Jun 20 13:44:48 xircon-w6567sz systemd[1]: Condition check resulted in Store a System Token in an EFI Variable being skipped.
Jun 20 13:44:48 xircon-w6567sz systemd[1]: Condition check resulted in First Boot Wizard being skipped.
Jun 20 13:44:48 xircon-w6567sz systemd[1]: Condition check resulted in First Boot Complete being skipped.
Jun 20 13:44:48 xircon-w6567sz systemd[1]: Condition check resulted in Rebuild Hardware Database being skipped.
Jun 20 13:44:48 xircon-w6567sz systemd[1]: Condition check resulted in Commit a transient machine-id on disk being skipped.
Jun 20 13:44:48 xircon-w6567sz systemd[1]: Condition check resulted in Repartition Root Disk being skipped.
Jun 20 13:44:48 xircon-w6567sz systemd[1]: Condition check resulted in Create System Users being skipped.
Jun 20 13:44:48 xircon-w6567sz systemd[1]: Condition check resulted in Update is Completed being skipped.
Jun 20 13:44:48 xircon-w6567sz systemd[1]: Condition check resulted in Manage Sound Card State (restore and store) being skipped.
Jun 20 13:44:48 xircon-w6567sz systemd[1]: Condition check resulted in SSH Key Generation being skipped.
Jun 20 13:44:56 xircon-w6567sz systemd[4578]: org.gnome.Shell@wayland.service: Skipped due to 'exec-condition'.
Jun 20 13:44:56 xircon-w6567sz systemd[4578]: Condition check resulted in GNOME Shell on Wayland being skipped.
@dalto@root - I get the “Condition check” errors from using the unit files or from @dalto’s amended fstab line - take them out and I don’t get them - reading up on it now, but what do they mean?
They are not errors - they are log messages on what the system is doing - and they are quite readable - they are nothing but information.
The amended fstab line is converted to mount/automount units and again - the messages has nothing to do with the mounting.
There is nothing in those messages which refers to the mounting resulting from the newly added mount sequence.
Your initial issue is that your network is not up when you try to mount the network share - and therefore the mount fails.
The above mentioned issue is remedied in the mount units by specifying that the mount units are not to be processed unless network is up.
Furthermore the units specifies when they are needed - at multi-user.target and remote-fs.target.
These conditions will ensure that the system does not mount unless network is up and a user requests it - which is only possible when reaching multi-user.target and network.target is reached.
Condition check - was this first boot? No - then wizard skipped
Condition check - was the first boot completed? Yes - then wizard skipped
You can apply the logic to the other entries as well.
We all manage the system in the way we find most effective and there is nothing wrong with either approach.
I don't care to argue for my way of doing things
But since you wanna know …
I know what’s in the manual of systemd mount units …
I like the systemd mount unit approach because it - for me - has been far easier to troubleshoot a single mount unit than to experiment with a mount command line which I then have to convert to a fstab options list and fiddle with creating the correct sequence for automounting when in the end all your hardwork fstab is parsed and converted to systemd mount units.
It is a breeze to create and test a new unit without having to roll through endless reboots until you get the fstab options list right.
Not trying to argue here either. You proposed an approach, I proposed an alternative approach that achieves the same goal.
Then you asked why so I answered
As side note, you don’t need to reboot to test changes in /etc/fstab. In fact, you probably shouldn’t unless you like living dangerously. I recommend testing them first before rebooting.
I just came over your other topic and was just thinking - if you are indeed connecting using wlan then use mount on demand as it is very difficult to control when systemd actually connects to the network.
I recommend testing them first before rebooting.