[BUG] Automount fail on reboot with Ubuntu 20.04

[jdaviescoates]

@p44 I'm not having any problems. Streaming music off of my Hetzner Storage Box mounted as a Cloudron Volume and connected to my Navidrome app as I type.

[nebulon]

If I am reading those version messages correctly, it does look like the automount on Ubuntu 20 has some kind of regression, while servers on 18 are working reliably?

[JOduMonT]

@nebulon said in Why my CIFS automatic mount fail on every reboot ?:

If I am reading those version messages correctly, it does look like the automount on Ubuntu 20 has some kind of regression, while servers on 18 are working reliably?

In plain english yes the issue seams to be only with Ubuntu 20.04

[jdaviescoates]

Possible related to this?

SMB1 disabled by default: can still be enabled via a /etc/samba/smb.conf config change;

https://wiki.ubuntu.com/FocalFossa/ReleaseNotes#Samba_4.11

More info here:
https://www.samba.org/samba/history/samba-4.11.0.html

Found via https://askubuntu.com/questions/1229929/cant-acces-nas-anymore-after-upgrading-to-20-04

[JOduMonT]

@jdaviescoates said in My CIFS automount fail on reboot with Ubuntu 20.04:

Possible related to this?

thank for your reach, I'll definitely give a try to this and come back soon.

[JOduMonT]

@jdaviescoates I just look at it
and on Cloudron Samba server is not installed
so nothing to configure in /etc/samba/* which actually don't even exist.

WEBDAV

I have the same behavior with webdav
on reboot I have to login and do mount -a

here the option for my davfs in /etc/fstab: rw,_netdev,uid=yellowtent,gid=yellowtent,file_mode=0660,dir_mode=0770 0 0
I also tried with auto and defaults

few people suggest to use rc.local

[JOduMonT]

I just got an idea
@nebulon
it is possible than cloudron mount the volumes before my automount so then the target directory of my automount is not empty ?

Also how could I destroy thoses volumes the GUI don't make it happen ?

[JOduMonT]

@jodumont said in My CIFS automount fail on reboot with Ubuntu 20.04:

it is possible than cloudron mount the volumes before my automount so then the target directory of my automount is not empty ?

nope, even without any volumes configured in Cloudron
CIFS and WEBDAV won't mount automatically

[JOduMonT]

@nebulon and @girish

I just copy the config (/etc/fstab and /etc/davfs2/secret) to my Ubuntu 20.04LTS Desktop
and my webdav mount automatically on the reboot.

So it seams to be a bug on the cloudron side.

[nebulon]

Cloudron itself does not handle any mount points as such. So this looks like this is some issue with 20.04 server then. Note that the desktop flavor has a lot more things installed usually, which may or may not trigger automounting correctly.

[JOduMonT]

@nebulon said in [BUG] Automount fail on reboot with Ubuntu 20.04:

Cloudron itself does not handle any mount points as such. So this looks like this is some issue with 20.04 server then. Note that the desktop flavor has a lot more things installed usually, which may or may not trigger automounting correctly.

I have no doubt of the quality of coding from the Cloudron Team
but I just boot an ubuntu 20.04 LTS at Hetzner
did

apt update
apt install -y davfs2
mkdir /mnt/storagebox

than cut and past my 2 lines
1 from /etc/fstab
1 for /etc/davfs2/secret

reboot and it work

so yes Ubuntu Desktop have probably more fuse than server but now the only difference is Cloudron.

[nebulon]

thanks for testing, so then probably one of the dependencies we install, somehow changes either the init order or even disables some bits there. Looks like we have to debug this further then on fresh installations to get some more information what systemd does differently in both scenarios.

[JOduMonT]

@nebulon said in [BUG] Automount fail on reboot with Ubuntu 20.04:

Looks like we have to debug this further then on fresh installations to get some more information what systemd does differently in both scenarios.

I'll run an fresh install of Cloudron than install davfs2 just to be sure

[JOduMonT]

@jodumont said in [BUG] Automount fail on reboot with Ubuntu 20.04:

I'll run an fresh install of Cloudron than install davfs2 just to be sure

so boot up a new instance Ubuntu 20.04 LTS @Hetzner
ran

wget https://cloudron.io/cloudron-setup
chmod +x ./cloudron-setup
./cloudron-setup

reboot than install davfs2 apt install -y davfs2
and configure /etc/fstab and /etc/davfs2/secrets
reboot

it don't mount automatically
but mount without issue with mount -a

[nebulon]

@jodumont I was able to reproduce this now also outside of hetzner on 20.04...not yet sure why and what causes the difference

[nebulon]

To give some update, this is DNS related and how the init sequence works on 20.04 now.
Problem is at the point when systemd decides to attempt to mount the remote filesystems, unbound, the dns resolver is not yet started. This means the remote fs cannot be mounted.

There are currently two workarounds:

1. Instead of using the DNS name in the fstab entry, just use the IP
2. add x-systemd.automount as an additional argument for the mountpoint in the fstab entry

Ideally we find a better flow by tweaking some of the init order in the future.

For now I've added that option requirement at https://docs.cloudron.io/backups/#cifs

[robi]

@nebulon what about a retry after the initial failure after unbound loads?

maybe add a mount -a at the end of the unbound script?

[JOduMonT]

@nebulon said in [BUG] Automount fail on reboot with Ubuntu 20.04:

Instead of using the DNS name in the fstab entry, just use the IP

I'm old school, I prefer IP
So it is probably related to unbound-resolvconf no ?:

Also on my side, by default my Hetzner NAS return me an IPv6, I didn't even know my Cloudron box as an IPv6

it is the same on your side ?

[JOduMonT]

@robi said in [BUG] Automount fail on reboot with Ubuntu 20.04:

@nebulon what about a retry after the initial failure after unbound loads?
maybe add a mount -a at the end of the unbound script?

How disabling the IPv6 in Cloudron

[girish]

@jodumont said in [BUG] Automount fail on reboot with Ubuntu 20.04:

So it is probably related to unbound-resolvconf no ?:

Issue is related to Cloudron. We have an internal DNS server (unbound) and it's configured in such a way that it has to start after docker (very tricky to make it start before docker). Unfortunately, because the DNS starts only after docker, it's a bit too late for services like network mounts which start before them. Which is why changing the mount from name based to IP makes it all work.

I guess the fix is to change the way DNS server starts up but this is quite a complex task.