Having trouble with .mount and .automount in Manjaro

The problem I am having is that the computer takes 2 min to get to the login screen when the .automount is enabled.

Here are my .mount and .automount files:

[demo@Manjaro ~]$ cat /etc/systemd/system/home-demo-mnt-server-music.mount
[Unit]
Description=server music mount

[Mount]
What=//192.168.68.15/Music
Where=/home/demo/mnt/server/music
Type=cifs
Options=_netdev,rw,file_mode=0700,dir_mode=0700,uid=1000,gid=1000,iocharset=utf8

[demo@Manjaro ~]$
[demo@Manjaro ~]$
[demo@Manjaro ~]$ cat /etc/systemd/system/home-demo-mnt-server-music.automount
[Unit]
Description=server music mount
Requires=home-demo-mnt-server-music.mount

[Automount]
Where=/home/demo/mnt/server/music
TimeoutIdleSec=10m

[Install]
WantedBy=multi-user.target
1 Like

I dont understand the systemd part, but am I correct in guessing that your music filesystem is on another computer and you are doing some sort of mount like nfs across a network?

If so, I would be looking at whether it is spending a lot of time getting dhcp up on that network.
You may get some clues if you look at dmesg

2 Likes

The only thing I see in dmesg is this:

[  124.533686] CIFS: No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3.1.1), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3.1.1 (or even SMB3 or SMB2.1) specify vers=1.0 on mount.
[  124.533688] CIFS: enabling forceuid mount option implicitly because uid= option is specified
[  124.533689] CIFS: enabling forcegid mount option implicitly because gid= option is specified
[  124.533690] CIFS: Attempting to mount //192.168.68.15/Music
1 Like

The timestamps show that is not consuming much time.
I wonder where else we can look to try and see what is going slow?
Systemd logs maybe?

Or, when the computer is sitting there taking 2 mins to get to the login screen, can you ssh into it and look at what processes are consuming time ( eg with top)

2 Likes
[demo@Manjaro ~]$ systemd-analyze blame
2min 267ms systemd-networkd-wait-online.service
    3.758s NetworkManager-wait-online.service
     780ms linux-modules-cleanup.service
     701ms dev-nvme0n1p11.device
     621ms NetworkManager.service
     445ms systemd-hwdb-update.service
     381ms ldconfig.service
     242ms upower.service
     223ms cups.service
     221ms tlp.service
     204ms user@1000.service
     175ms systemd-networkd.service
     174ms home-demo-mnt-server-music.mount
     153ms tailscaled.service
     117ms systemd-udev-trigger.service
      96ms polkit.service
      96ms systemd-tmpfiles-setup.service
      92ms systemd-modules-load.service
      78ms systemd-hostnamed.service
      78ms lvm2-monitor.service
      76ms udisks2.service
      75ms systemd-tmpfiles-clean.service
      73ms systemd-logind.service
      72ms systemd-journald.service
      66ms systemd-udevd.service
      63ms systemd-journal-catalog-update.service
      62ms colord.service
      60ms ModemManager.service
      57ms systemd-resolved.service
      56ms boot-efi.mount
      56ms systemd-timesyncd.service
      56ms systemd-journal-flush.service
      55ms home.mount
      53ms systemd-update-utmp.service
      52ms systemd-fsck@dev-disk-by\x2duuid-385A\x2d127E.service
      39ms dbus-broker.service
      37ms systemd-user-sessions.service
      37ms bluetooth.service
      34ms systemd-tmpfiles-setup-dev-early.service
      32ms avahi-daemon.service
      32ms systemd-fsck@dev-disk-by\x2duuid-1f7a0eb8\x2df3e9\x2d46ef\x2da88a\x2de3ae0ed0233d.service
      30ms systemd-sysusers.service
      29ms systemd-tmpfiles-setup-dev.service
      24ms alsa-restore.service
      24ms systemd-vconsole-setup.service
      22ms rtkit-daemon.service
      19ms modprobe@dm_mod.service
      18ms tmp.mount
      17ms systemd-backlight@backlight:intel_backlight.service
      16ms systemd-networkd-persistent-storage.service
      16ms systemd-update-done.service
      15ms systemd-remount-fs.service
      14ms proc-sys-fs-binfmt_misc.mount
      13ms user-runtime-dir@1000.service
      13ms dev-hugepages.mount
      13ms wpa_supplicant.service
      13ms modprobe@loop.service
      13ms dev-mqueue.mount
      12ms sys-kernel-debug.mount
      12ms sys-kernel-tracing.mount
      12ms clamav-daemon.socket
      11ms kmod-static-nodes.service
      11ms systemd-random-seed.service
      11ms systemd-udev-load-credentials.service
      10ms modprobe@configfs.service
       9ms modprobe@drm.service
       8ms modprobe@fuse.service
       7ms systemd-sysctl.service
       7ms sys-kernel-config.mount
       5ms sys-fs-fuse-connections.mount
2 Likes

@nevj Isn’t that a cool log thing you can do with systemd? :grinning_face:

3 Likes

@Maybl8 Is the mount accessible afterward? Port 139 open?

2 Likes

I had modified the .mount and .automount files so I put them back the way I started with and now I don’t have the delay is starting the computer but the delay happens if I start dolphin right away. If I wait a couple of minutes dolphin starts right up.

Here are the files as they exist now.

[demo@Manjaro ~]$ cat /etc/systemd/system/home-demo-mnt-server-music.automount
[Unit]
Descripion=server music mount

[Automount]
Where=/home/demo/mnt/server/music
TimeoutIdleSec=10

[Install]
WantedBy=multi-user.target
[demo@Manjaro ~]$
[demo@Manjaro ~]$
[demo@Manjaro ~]$ cat /etc/systemd/system/home-demo-mnt-server-music.mount
[Unit]
Description=server music mount
After=network-online.target
Wants=network-online.target

[Mount]
What=//192.168.68.15/Music
Where=/home/demo/mnt/server/music
Type=cifs
Options=rw,file_mode=0700,dir_mode=0700,uid=1000,gid=1000,iocharset=utf8,_netdev,vers=3.0
TimeoutSec=30

[Install]
WantedBy=multi-user.target
1 Like

I would guess it is a startup ordering problem… trying to mount before some dependency is available.

Yeah, but I would suggest systemd’s complexity is the cause of the problem, particularly when combined with NetworkManager’s complexity.

1 Like

All my music and movies and stuff are on a NAS share…

But I use NFS…

I just export the “parent” and mount it on my Ubuntu 24.04 via /etc/fstab…

I never see any delays… In some older versions of Ubuntu - the mount argument in /etc/fstab didn’t work for some reason… but it does on 24.04 and it worked on Pop!_OS 22.04 when I was running that…

I’d always favour NFS over SMB/CIFS anyway… Unless your file server is a Windows machine I guess - you’re stuck with CIFS?

I’m lazy - how I usually format my /etc/fstab is I manually mount the NFS share first time, then “tail -1” my /etc/mtab - then append that last line to /etc/fstab - and it mounts on boot :

baphomet.local:/mnt/BARGEARSE /mnt/BARGEARSE nfs4 rw,relatime,vers=4.1,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=red.ac.t.ed,local_lock=none,addr=re.dact.e.d 0 0

How long before the SystemD twonks disable /etc/fstab and do it all through SystemD? That’s probably the day I opt for a non SystemD focussed distro! :smiley:

1 Like

I shall be expecting you soon.

2 Likes

Amen brother :smiley:

2 Likes