Mount cifs works on RL 8 but not on RL9?


I have 2 Rockylinux server, one is 8.9 the other one is 9.4.
Both use the same “mount” command to connect to an old IBM as400, to grab a csv and publish some data on a webserver.
My problem is:
everything worked for a year, now the command on RL 9 is not working anymore but RL8 works fine.

Command is:

mount -t cifs //ipaddr/path/PATH/PATH/ /mnt/mountfolder -o vers=1.0,username=xxx,password=xxx,nofail,ro,noserverino

But when I launch it from the consolle this is the message:

mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)

This is what I see from dmesg

[119134.706595] CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers
[119134.706601] CIFS: Attempting to mount //ipaddr/path/PATH/PATH/
[119134.710001] CIFS: VFS: cifs_mount failed w/return code = -22

Can’t find other details.
I know vers=1.0 is not ideal but it’s necessary. Maybe RL9 doesn’t allow mounting cifs with vers 1.0 anymore?

Any help is apreciated, not a super-expert here.

Can you try removing the parameters from the end of the line. Eg, nofail noserverino in case one of these are the fault.

Ideally, providing mount -vvv would give a lot more error output and would help in diagnosing which flag is the problem. I doubt very much the vers=1.0 is the issue here.


  • if i remove vers=1.0
mount error: Server abruptly closed the connection.
This can happen if the server does not support the SMB version you are trying to use.
The default SMB version recently changed from SMB1 to SMB2.1 and above. Try mounting with vers=1.0.
mount error(112): Host is down
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
  • if i remove username, command try to connect with user root (wrong)
  • if i remove password, the server ask me for it and when I manually insert it this is the strange message:
mount.cifs kernel mount options: ip=10.10.x.x,unc=\\10.10.x.x\FIRST_ FOLDER_ OF_THE_PATH,vers=1.0,user=as400,prefixpath=SECOND_ FOLDER_OF_THE_PATH/THIRD_ FOLDER_OF_THE_PATH/,pass=********
mount error(22): Invalid argument
  • if i remove “nofail, ro, noserverino” message is always
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)

Seems that problem is caused by the password argument?

Where you are trying to mount from looks suspect ‘//ipaddr/path/PATH/PATH/’ , it is usually ‘//server/share’ not a UNC.

Believe me: on RL8 the mount command is working perfectly fine with the exact same settings and even on RL9 it worked for a year. Don’t know if an update broke something, couple of weeks ago.
Anyway, if this is the problem, how could I mount (and download) a specific file located in a subfolder “//ipaddr/path/PATH/PATH/” ?


Possibly something in 9.4 kernel assuming you upgraded to 9.4 from say 9.3. You could boot the previous kernel from the grub menu and see if it works again.

1 Like


Booted “old” kernel 5.14.0-362.24.1.el9_3.0.1.x86_64 and problem is solved.
Retried with latest 5.14.0-427.16.1.el9_4.x86_64 and problem appears again.

Another confirm is that our last working file transfer was on 11 May, on 12 of May RL9.4 was automatically updated.

So, what can we do now? If I reboot on the old kernel it will update by itself or move to 9.4 at the first reboot? By the way I don’t like to keep the server not updated, any idea how to solve this on 9.4 ? Anything to check?


Red Hat made a load of changes in 9.4 kernel, so without being a part of the infrastructure team, I’m unable to say what that was. @nazunalika might be able to tell what was changed on that.

Alternatively, elrepo can be used, and you can use either kernel-lt or kernel-ml, which will be 6.x kernels rather than 5.14.x kernels that are in Rocky by default. That may be worth trying and using instead. There is also a possibility that Rocky SIG Kernels could also be used which could have the updated 5.14.x kernel, but with the options enabled that you are looking for.

1 Like

Tried installing elrepo LT 6.1.92-1.el9.elrepo.x86_64 , problem is fixed. (had to disable secure boot, otherwise system won’t boot).
Is this kernel a safe solution for a production environment?

To me problem is fixed, however any other details on this topic could be helpful for someone else.

Many thanks!

I would not say “solved”. “Located”, perhaps. We now know that it is something where 5.14.0-427.el9 differs from 5.14.0-362.el9.

One could browse the changelog:
rpm -q --changelog kernel-5.14.0-427.16.1.el9_4 | less
or more to the point:

rpm -q --changelog kernel-5.14.0-427.16.1.el9_4 | grep -iE "^\*|smb|cifs" | less

but whether any of it is telling is an another story.

There are two options for such boot issue:

  1. Exclude kernel packages from updates
  2. Edit /etc/sysconfig/kernel to prevent update from changing GRUB default. Then set the 5.14.0-362.24.1 as the default entry. This is probably the “cleaner” way

ELRepo builds the kernel packages from upstream sources. Kernel developers do patch the LT sources and ELRepo is a reputable repo.

1 Like

You’re right, “located” is more correct than “solved”, sorry but English is not my native language.
I just tried to open changelog as you suggest but it’s too much for my basic linux skills to find anything relevant :slight_smile:
About elrepo kernel 6 OK, good, I will keep it.


There was a Kconfig setting

old : linux-5.14.0-362.24.1.el9_3/fs/cifs/
new : linux-5.14.0-427.16.1.el9_4/fs/smb/

they changed the kernel source, cifs has gone, and now it’s called smb, and the Kconfig is different