Mounting a NAS using systemd - mount error: cifs filesystem not supported by the system

[mzuniga]

Hi, all!

I have a NAS, located on https://192.168.1.222:5201/, and accessible via AFP:
afp://xylan.local/fro on xylan/.

I would like to mount this, using systemd. I have created the file:
/etc/systemd/system/media-nas.mount
containing:

[Unit]
Description=Mount of NAS (/media/nas)

[Mount]
What=//192.168.1.222/fro
Where=/media/nas
Type=cifs
Options=iocharset=utf8,rw,file_mode=0777,dir_mode=0777,user=muna,password=[PASSWORD]
TimeoutSec=30

[Install]
WantedBy=remote-fs.target
WantedBy=multi-user.target

However, running:
sudo systemctl start media-nas.mount
returns the output:
Job failed. See "journalctl -xe" for details.

$ journalctl -xe returns:

Aug 12 16:28:04 tuxwarrior systemd[1]: Mounting Mount of NAS (/media/nas)...
░░ Subject: A start job for unit media-nas.mount has begun execution
░░ Defined-By: systemd
░░ Support: https://forum.manjaro.org/c/support
░░ 
░░ A start job for unit media-nas.mount has begun execution.
░░ 
░░ The job identifier is 43440.
Aug 12 16:28:04 tuxwarrior mount[233260]: mount error: cifs filesystem not supported by the system
Aug 12 16:28:04 tuxwarrior mount[233260]: mount error(19): No such device
Aug 12 16:28:04 tuxwarrior mount[233260]: Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
Aug 12 16:28:04 tuxwarrior systemd[1]: media-nas.mount: Mount process exited, code=exited, status=32/n/a
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://forum.manjaro.org/c/support
░░ 
░░ An n/a= process belonging to unit media-nas.mount has exited.
░░ 
░░ The process' exit code is 'exited' and its exit status is 32.
Aug 12 16:28:04 tuxwarrior systemd[1]: media-nas.mount: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://forum.manjaro.org/c/support
░░ 
░░ The unit media-nas.mount has entered the 'failed' state with result 'exit-code'.
Aug 12 16:28:04 tuxwarrior systemd[1]: Failed to mount Mount of NAS (/media/nas).
░░ Subject: A start job for unit media-nas.mount has failed
░░ Defined-By: systemd
░░ Support: https://forum.manjaro.org/c/support
░░ 
░░ A start job for unit media-nas.mount has finished with a failure.
░░ 
░░ The job identifier is 43440 and the job result is failed.

It seems like cifs is the problem:
mount error: cifs filesystem not supported by the system

Does anyone know how I can fix this issue? Should I use something else than cifs?

[Jim.B]

How about an NFS share?

[megavolt]

@mzuniga

mount error: cifs filesystem not supported by the system

Did you perform a kernel upgrade and not reboot? After an upgrade, the path to the module changes so that it can no longer find the old path.

[mzuniga]

Thanks a lot, @megavolt. Spot on. A reboot solved the issue.

[winnie]

@megavolt

After an upgrade, the path to the module changes so that it can no longer find the old path.

This is one of the reasons I use the kernel modules hook for pacman/Pamac. I can still use my system seamlessly without having to reboot after a kernel update.

[mzuniga]

@winnie

This is one of the reasons I use the kernel modules hook for pacman/Pamac. I can still use my system seamlessly without having to reboot after a kernel update.

Interesting. Do you mind sharing some info / links on how that can be done?

[winnie]

It’s not sleek nor perfect, but works well enough for me.

You install (from the official Arch Community repository; not from the AUR) the package: kernel-modules-hook

Now whenever you update your kernel (even the kernel of the currently live running system), the modules under /usr/lib/modules/ will remain preserved, thanks to the included and auto-enabled pacman “hook”.

It also includes a systemd service (linux-modules-cleanup.service) which will automatically prune old modules on a schedule (I believe kernels that are four weeks old from installation get pruned; however it will not prune the currently running kernel.)

---

Here’s an example if you’re not using this hook:

You’re currently running on kernel 5.15.57.

Under /usr/lib/modules/ the directories that exist:

• 5.15.57-1-MANJARO

Stable Updates are available, and one such update is linux515 which will update the kernel from 5.15.57 → 5.15.59

The rug has been swept from underneath your feet! Because now under /usr/lib/modules/ is:

• 5.15.59-1-MANJARO

Yet the directory 5.15.57-1-MANJARO is gone! Poof! Such modules used by the currently running kernel that have not been loaded (or were recently unloaded) cannot be loaded when needed. This manifests as unpredictable and mysterious errors and issues.

---

Here’s an example if you are using this hook:

You’re currently running on kernel 5.15.57.

Under /usr/lib/modules/ the directories that exist:

• 5.15.57-1-MANJARO

Stable Updates are available, and one such update is linux515 which will update the kernel from 5.15.57 → 5.15.59

Now under /usr/lib/modules/ are:

• 5.15.57-1-MANJARO
• 5.15.59-1-MANJARO

Because the rug was not “swept from underneath your feet”, you can continue to use the currently running system normally. You can reboot at a later time if you still need to keep your system running for the meantime (and there are very legitimate reasons for this. I hate rebooting because I lose all my data/metadata cache’d into RAM for a snappier system.)

---

I have to mention this, even if it’s unpopular: a distro like Ubuntu handles kernel updates properly

It’s a very simple reason really. They treat each minor version of the kernel as its own package. Whereas the major version of a kernel is simply a meta-package that tells the system which kernel “train” to keep updating.

To this day I believe that Arch (and Arch-based distros) would be less of a headache for users, new and established, if they didn’t pull the rug from under our feet every time there’s a minor update to the current major kernel version.

It could be implemented with logic as simple as:

“If there’s an update to the major kernel version of which the user is currently running, treat each minor kernel version as its own package and have in place a ‘pruning’ service that automatically removes older kernels, with the important exception of the currently running kernel.”

Here’s how this could theoretically work:
Actually, it’s not just theoretical. It does work! Just look at Ubuntu and Mint. (And Debian.)

If you’re on the “linux515 train”, then you might currently be running on 5.15.57, which was brought in by the package named linux515-5.15.57

If there’s an update for the “linux515 train”, then you end up “updating” by installing the package linux515-5.15.59, which will not overwrite anything nor remove the current kernel’s modules.

You keep this up on the “linux515 train”, and the next time you reboot, you’ll reboot into the newest version of the 5.15 series, and the pruning service can now safely remove linux515-5.15.57 since it is no longer currently active. And you’re also keeping your system up-to-date and are running on the latest updated kernel as well.

---

Come on Arch Linux people… this makes more sense. The proof is in the fact that “pulling the rug from under our feet” manifests as strange errors and bugs.

@mzuniga: If @megavolt didn’t outright inform you that you need to reboot to be able to use your NAS shares, imagine how confused you’d be trying to troubleshoot why you can’t access your shares? And then at a later day in the future when you do reboot, and your shares start magically working again, you’d be unsure why it “fixed itself”.

[mzuniga]

Awesome, @winnie. Thanks a lot for the detailed information!