| Summary: | failure to mount (cifs) NAS units in Mga8 | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Rod Goslin <rod> |
| Component: | RPM Packages | Assignee: | Mageia tools maintainers <mageiatools> |
| Status: | NEW --- | QA Contact: | |
| Severity: | major | ||
| Priority: | Normal | CC: | juergen.harms, nicolas.bachelet1, ouaurelien |
| Version: | Cauldron | ||
| Target Milestone: | Mageia 9 | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | MGA8TOO regression | ||
| Source RPM: | drakconf-13.27-1.mga8.src.rpm | CVE: | |
| Status comment: | |||
|
Description
Rod Goslin
2021-07-09 05:52:21 CEST
Reproduced. Our tool is broken. Assigning. CC:
(none) =>
ouaurelien Same / similar problem here, but: not in the past - cifs mounting worked perfectly until some recent update of the samba packages. The problem became evident when I re-booted into Kernel 5.15.20 (just befor christmas)
I only started looking into this now (travelling and waiting for the result of fixing bugzilla 29641): the problem persists, the fixed samba packages (xxx-4.14.11-1.mga8) did not fix the issue.
I realize that the problem I am seeing only started in December 2021 and does not really fit into a bugzilla report relative to something observed much earlier. Nevertheless, here are details on what I have observed (please say if I should open a new report):
- In normal operation (OK so far), my cifs file-system is mounted according to specifications in my /etc/fstab:
//192.168.0.1/fritz.nas /fritzbox cifs username=harms,credentials=/etc/samba/smbcredentials,noserverino,noauto,defaults,uid=1000,gid=1000,forceuid,forcegid,vers=3.1.1 0 0
Trying to simplify, I did a command-line mount with minimal options
sudo mount -t cifs //192.168.0.1/fritz.nas /mmm
After responding to the password query, the system replies:
mount error: cifs filesystem not supported by the system
mount error(19): No such device
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
Neither dmesg nor journalctl provide any further information. What can I do to help clarifying?
One oberservation: the latest update of cifs-utils (6.11-21) dates from 31.5.21 - i.e cifs-utils has not been updated with recent updates of samba; is this correct?
My NAS server is part of my Fritzbox 7590 (at 192.168.0.1, latest software, no recent update). It works with support for cifs 3.1 (the option to also support cifs 1.0 has now been switched on)CC:
(none) =>
juergen.harms check dmesg for errors like: "modprobe: ERROR: could not insert 'cifs': Cannot allocate memory" and if that is found, try kernel-5.15.12-2.mga8 from Core Updates Testing That would be kernel 5.15.13-1 now Sorry for the long delay, I have been burgled and had to do much dealing-with. - looking at dmesg: searched for cifs - no reference containing cifs - modprobe: except some messages relative to my bios, nothing alarming - nevertheless installed kernel-5.15.13-1: problem persists More background: I had a file-system with an old Mageia-8 installation hanging around. Did a full upgrade of that system (hence, installed all the samba 4.14.11 upgrades), but booted into its original kernel (5.15.6). Result: no problem doing a cifs mount on that system. And thanks for picking this up! working without easy access to shared data is somewhat painful I can confirm I had the cannot allocate memory and could not insert cifs errors until I tried the kernel 5.15.13-1 which solves the issue on all my testing VMs => in my environment, the problem is solved. I saw that some of my testing VMs were able to mount CIFS volumes at boot with 5.15.x kernels and one of the VMs was still able to mount CIFS volumes with the affected kernels. I have absolutely no clue why, but I do not know if it matters. Regarding Juergen's issue, either the vers option is not correct, or the server needs some updates/configuration (ex: disable SMB1)? Thanks CC:
(none) =>
nicolas.bachelet1 @HomeBoy TAZ: > either the vers option is not correct ... : incorrect hypothesis, tested by having mounts done with the option-list that figures in /etc/fstab, and fstab options being copy-pasted to all OS partitions in question > or the server needs ... : equally non-valid - the configuration of the server is frozen by its manufacturer and has not been modified for a long time: it is the same server that is accessed by Mageia OS-partions with working and with failing cifs mounting. But: my reading of the facts has been wrong - I had suspected one of the samba or cifs packages or the kernel to cause the problem. This does not correspond to the following evidence: - when I install a new Mageia-8 partition, in a first phase I install a minimum system: only a bare Xfce system (only packages needed for running Xfce, things like terminals, plain text editing); - at the end of this first phase (after the initial boot), I install cifs-utils and immediately try a cifs-mount: that ALWAYS IS WORKING OK !; - in a second phase I do "urpmi --auto-select" (cifs still working afterwards) and), - followed by "urpmi <huge list of all user required additional packages>"; it is AFTER THIS URPMI that cifs mounts have STOPPED WORKING. Looks conclusive so far - but there is a totally weird random element: sometimes cifs-mount comes out working after loading user required packagetand I obtain a correctly working system. Trying to split this huge urpmi and to observe after which package cifs gets broken provides unconclusive and randon results. This randomness would explain why different users report varying problems (for instance, on my laptop I only have broken cifs systems. This activity of repetitive system-installs eats up much time, for the moment I am giving up. Additional things I have done: caught up installing the most recent bios, running (quick) hardware tests, thoroughly compared system partitions ( rpm -qa, contents of /etc/samba/smb.conf and /etc/samba/smbcredential = where I keep user + password for cifs mounting). Plus: there is plenty of memory available on the root+home partition |