FS#57474 - [linux] Kernel general protection fault when trying to use CIFS with 4.15.2-2-ARCH
Attached to Project:
Arch Linux
Opened by Daniel Kamil Kozar (XAVeRY) - Sunday, 11 February 2018, 22:36 GMT
Last edited by Toolybird (Toolybird) - Thursday, 02 March 2023, 07:01 GMT
Opened by Daniel Kamil Kozar (XAVeRY) - Sunday, 11 February 2018, 22:36 GMT
Last edited by Toolybird (Toolybird) - Thursday, 02 March 2023, 07:01 GMT
|
Details
When copying files into a CIFS-mounted share on a server in
my LAN, the process suddenly stops and a "general protection
fault" message along with a stack trace can be seen in the
kernel messages. The server is a Samba 4.7.4. The machine
usually needs a reboot after the message appears.
Please see the attached file for the full contents of the kernel messages. |
This task depends upon
Closed by Toolybird (Toolybird)
Thursday, 02 March 2023, 07:01 GMT
Reason for closing: None
Additional comments about closing: Very old/stale bug. Please request reopen if still reproducible on current kernels.
Thursday, 02 March 2023, 07:01 GMT
Reason for closing: None
Additional comments about closing: Very old/stale bug. Please request reopen if still reproducible on current kernels.
1. Writing an 800 KB PDF to a CIFS mounted location using a new file name. This first write always works.
2. Attempt to write the same 800 KB PDF again, but to a different file name. This will hang and produce a protection fault.
3. Unmount etc will now hang.
I have found a workaround is to add "vers=1.0" to /etc/fstab:
//FS1/data /home/username/data cifs vers=1.0,credentials=/home/username/smbcredentials,uid=1000
With this workaround the above test can be repeated without any failures, hangs or errors in dmesg.
smbclient version 4.7.5
mount.cifs version 6.7
mount options in fstab:
vers=3.0,uid=<redacted>,gid=<redacted>,file_mode=0644,dir_mode=0755,iocharset=utf8,credentials=<redacted>,domain=<redacted>,cache=strict,sec=ntlmssp,x-systemd.automount
Just wondering why we went back all the way to 1.0 here
I will be doing some tests here soon, and can report.
has this been thrown upstream? i see on the ubuntu tracker that they have an upstream tag, but does that throw anything upstream?
is not aware of the issue or believes it has already been resolved. I would suggest testing 4.19-rc3 to see if the issue is still present and if so contact upstream.