You are not logged in.
I have just discovered that the last update of util-linux and util-linux-libs to 2.39-8 has also destroyed my cifs mounts.
Reverting to previous 2.39-4 version of both packages recovers everything.
So most probably we have to dig around there for a cause...
Last edited by papavlos (2023-06-26 21:01:43)
Offline
I have just discovered that the last update of util-linux and util-linux-libs to 2.39-8 has also destroyed my cifs mounts.
Reverting to previous 2.39-4 version of both packages recovers everything.
https://github.com/util-linux/util-linu … able/v2.39 Changes from upstream note f94a7760ed7ce81389a6059f020238981627a70d and 1bd85b64632280d6bf0e86b4ff29da8b19321c5f have already been applied to 2.39-4
https://gitlab.archlinux.org/archlinux/ … aight=true Changes to the PKGBUILD
Offline
Thanks @loqs for a light!
So lets then wait a while for a declutterig...
Offline
So lets then wait a while for a declutterig...
While waiting could you share more details of the failure on your system. Are the mounts mounted manually, fstab, .mount or something else. If manually please share the command and its output, if fstab please share the fstab entry and command or service output, e.t.c..
Offline
I mount my cifs drives in my fstab as follows (showing just the first one):
//NAS/nas6 /mnt/nas6 cifs user=***,password=***,uid=1000,gid=1000,iocharset=utf8,vers=2.1,noauto,x-systemd.automount,rw 0 0System boots without any messages in journalctl or dmesg.
After issuing
ls -la /mnt/nas6
there is strange output
ls: cannot open directory '/mnt/nas6': No such devicethe directory /mnt/nas6 exists, of course.
sudo journalctl -b shows one error:
cze 12 20:06:20 asus systemd[1]: mnt-nas6.automount: Got automount request for /mnt/nas6, triggered by 1266 (ls)
cze 12 20:06:20 asus systemd[1]: Mounting /mnt/nas6...
cze 12 20:06:20 asus kernel: FS-Cache: Loaded
cze 12 20:06:20 asus kernel: Key type dns_resolver registered
cze 12 20:06:20 asus kernel: Key type cifs.spnego registered
cze 12 20:06:20 asus kernel: Key type cifs.idmap registered
cze 12 20:06:20 asus kernel: CIFS: Attempting to mount \\NAS\nas6
cze 12 20:06:20 asus mount[1268]: mount error(13): Permission denied
cze 12 20:06:20 asus mount[1268]: Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
cze 12 20:06:20 asus kernel: CIFS: VFS: cifs_mount failed w/return code = -13
cze 12 20:06:20 asus systemd[1]: mnt-nas6.mount: Mount process exited, code=exited, status=32/n/a
cze 12 20:06:20 asus systemd[1]: mnt-nas6.mount: Failed with result 'exit-code'.
cze 12 20:06:20 asus systemd[1]: Failed to mount /mnt/nas6.and also
sudo dmesgreturns the same error info:
[ 182.079510] FS-Cache: Loaded
[ 182.081204] Key type dns_resolver registered
[ 182.126200] Key type cifs.spnego registered
[ 182.126208] Key type cifs.idmap registered
[ 182.126559] CIFS: Attempting to mount \\NAS\nas6
[ 182.156684] CIFS: VFS: cifs_mount failed w/return code = -13so nothing meaningful, I guess, as the "permission denied" error may have million of causes.
Last edited by papavlos (2023-06-12 19:22:45)
Offline
My issue with cifs mounts is solved, but actually I don't know why...
The solution:
I have created a text file /root/nas.pwd and put there
user=***
password=***Then replaced all entries in my fstab as follows:
//NAS/nas6 /mnt/nas6 cifs credentials=/root/nas.pwd,uid=1000,gid=1000,iocharset=utf8,vers=2.1,noauto,x-systemd.automount,rw 0 0Finally, I have updated util-linux and util-linux-libs to the current stable 2.39-9.
After reboot my shares are properly mounted and operational.
Why?
What is even more tricky: after commenting out my cifs shares in fstab and rebooting I can still properly mount them manually with mount.cifs:
sudo mount.cifs //NAS/nas6 /mnt/nas6 -o user=***,password=***,uid=1000,gid=1000,iocharset=utf8,vers=2.1,noauto,x-systemd.automount,rwApparently there is something screwed up in the current mount - I can't provide cifs share credentials directly, while it works with the credentials file.
And my credentials consist only of Latin letters. No special or national characters...
Can anybody check it and confirm? If yes, I could open a bug...
Last edited by papavlos (2023-06-14 22:13:31)
Offline
There are some issues with fstab option handling: https://bbs.archlinux.org/viewtopic.php?id=286053
But
While some versions of the cifs kernel module accept user= as an abbreviation for this option, its use can confuse the standard mount program into thinking that this is a non-superuser mount. It is therefore recommended to use the full username= option name.
Offline
@papavlos what if you revert https://github.com/util-linux/util-linu … 8a1915bb09
Offline
There are some issues with fstab option handling: https://bbs.archlinux.org/viewtopic.php?id=286053
But
man mount.cifs wrote:While some versions of the cifs kernel module accept user= as an abbreviation for this option, its use can confuse the standard mount program into thinking that this is a non-superuser mount. It is therefore recommended to use the full username= option name.
You're absolutely right! Putting the full 'username' instead of 'user' as the option did the trick! So now it works (again) with explicit credentials in fstab:
//NAS/nas6 /mnt/nas6 cifs username=***,password=***,uid=1000,gid=1000,iocharset=utf8,vers=2.1,noauto,x-systemd.automount,rw 0 0Now the question is one step more precise: Why it used to work, since ages, with 'user' and 'username' and now it works only with 'username'?
So the quoted man description should have explicit restriction:
...It is therefore required to use the full username= option name.
Regarding the second hint:
@papavlos what if you revert https://github.com/util-linux/util-linu … 8a1915bb09
I need more time. I'll check it after my office shift. I think this may be the right clue.
Offline
Splitting from https://bbs.archlinux.org/viewtopic.php?id=286433 by request
Offline
Splitting from https://bbs.archlinux.org/viewtopic.php?id=286433 by request
Thanks!!! ![]()
Offline
No problem, btw that was pretty much a picture-book case for a good report, so thanks for the realization of the need to split and the relevant report giving the appropriate reasoning.
Offline
@papavlos what if you revert https://github.com/util-linux/util-linu … 8a1915bb09
Did it. Yes. Reverting this commit fixes the issue.
Now mount -t cifs can use explicit options "user=***,password=***,...", as well as "user=***,pass=***,...".
Submitted this as an issue: https://github.com/util-linux/util-linux/issues/2315
Thank you loqs for your accurate hint!
Let's wait now for any final answer from util-linux: either a positive solution adopted by our distribution, or final rejection of my issue, but then I will fight for amending man pages respectively.
Then I will mark this thread as solved.
Offline
It's been fixed with the recent update of util-linux to 2.39-11. Solved.
Offline