Description of problem:The procedure in MCC for mounting (cifs) external systems still does not work Version-Release number of selected component (if applicable): How reproducible: At all times Steps to Reproduce: 1.Normal procedure to create a mount 2. 3. I'm pleased to note that certain aspects of the procedure for creating Windows Shares in Network Sharing now seems to work consistently. In the past the option has been hit and miss for a very long time. In Mga8, however, the search did find the available servers. But the remainder of the procedure does not work. There are a number of reasons for this:- 1. the servers are located by name, but the created entry in fstab requires the server to be identified by it's IP address, to work. This is commonly supplied by the /etc/hosts file, which is external to the share install. 2. whilsst it is passible to enter the user name of the share, as a known, there is no longer a facility to add the password. The passord can be added , when issuing the 'mount -a' command, but this does require that the person creating the share knows the password. 3. In the past the confidential nature of the password has been preserved by means of a 'credentials' file in /etc/samba. This facility no longer appears to be present. In recent versions of Mga, the only way of creating shared external directories has been to ignore the procedure in MCC and create the whole thing, by hand, as it were.
Reproduced. Our tool is broken. Assigning.
CC: (none) => ouaurelienTarget Milestone: --- => Mageia 9Assignee: bugsquad => mageiatoolsSource RPM: (none) => drakconf-13.27-1.mga8.src.rpmSeverity: normal => majorVersion: 8 => CauldronWhiteboard: (none) => MGA8TOO regression
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