The patch does seem like a step forwards, but the warning messages are
still easy to miss and misleading. I would rather abort the connection
than risking a non-functional connection (in the case of the round-up I
described with PAGE_SIZE = 64 KiB). I do not think it is a good idea
either to
I had some difficulty with the test kernel, because the installation
command wanted to remove the running kernel, so I got a warning about
it. I think there was some kind of conflict with the normal 6.5.0-15
kernel. In the meantime, the kernel has been upgraded to 6.5.0-17, so I
removed all older
Thanks, I'll test the new kernel over the weekend.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2049634
Title:
smb: wsize blocks of bytes followed with binary zeros on copy,
For the benefit of the subscribers to this bug, who may not be following
the corresponding e-mail thread in the linux-cifs mailing list:
This bug does not only affect SMB 1.0, but all SMB versions. It will
probably bite you if you specify a wsize mount option with a number of
bytes which is not a
About the comment "users with a custom wsize", note that I didn't set a
custom wsize.
This is the script I am using to mount the SMB 1.0 shares:
https://github.com/rdiez/Tools/blob/master/MountWindowsShares/mount-
windows-shares-sudo.sh
There is no wsize parameter there. I did write above that
Many thanks for confirming this problem. I was worried that there might
be something wrong with the server, instead of with the Linux client.
In the meantime, I have posted about this to the linux-
c...@vger.kernel.org mailing list, so at least some people there are
already aware:
SMB 1.0 broken
I just realised that the offset to the first hole matches the default
wsize=16580 argument for SMB 1.0 mounts, or at least that is what "mount
-l" reports.
That is, cifs is writing each time wsize bytes with the right data + a
hole of 3900 bytes made of binary zeros. And the next blocks look the
I am attaching the other file version with the binary zero holes inside,
as copied back from the server.
** Attachment added: "testdata-back-from-server.txt"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2049634/+attachment/5744352/+files/testdata-back-from-server.txt
--
You received
I have done some more tests on a different computer with the same OS,
this time with the following Kernel version as reported by "uname -a":
Linux 6.5.0-15-generic #15~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC
Fri Jan 12 18:54:30 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
I generated a reproducible
I haven't tested much, but this corruption was obvious very quickly. I
just copied a few megabytes of files and got several corruptions. Most
files were compressed, and the easiest file to look at was a text file,
and the binary zeros were quickly visible in the text editor. I think
you will not
I have kept one corrupt text file (which I cannot post here), and I ran
this command on it:
grep --perl-regexp --text --byte-offset '\x00{3900}' my-corrupt-
text-file
The file has 2 blocks of binary zeros which should not be there. Their
offsets are random, but both blocks are exactly 3900
Today I temporarily reverted back to Kernel 6.2.0-39-generic, by
choosing it from the Grub bootloader, and the SMB 1.0 network shares
started working correctly again. I think it is clear that Kernel 6.5 is
broken in this respect.
Fortunately, package linux-image-6.2.0-39-generic is still
Public bug reported:
Hi all:
I upgraded my Ubuntu yesterday and automatically got the newer Linux
Kernel version 6.5.0-14-generic #14~22.04.1-Ubuntu. Previously, I was
running kernel version 6.2 .
I still have a legacy system on the network using SMB protocol version
1.0.
With the new kernel
This problem seems fixed now, or at least I am no longer having problems
with this Linux Kernel version:
6.2.0-34-generic #34~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Sep 7
13:12:03 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
Can somebody else confirm this?
I don't know yet how to check whether that
It is not GNU Make itself. If I pipe GNU Make's output to tee, then it
is tee that fails:
tee: 'standard output': Resource temporarily unavailable
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-signed in Ubuntu.
This problem happens with both the standard GNU Make 4.1 that comes with
Ubuntu 16.04.5, and with a self-compiled GNU Make 4.2.1.
The error only happens if make is writing to stdout. If you redirect to
a file like this:
make ... blah... blah... 2>&1 >"$HOME/Build.log"
Then it runs fine.
--
I have recently started experiencing the same problem.
Ubuntu 16.04.5 LTS
Kernel 4.15.0-45-generic #48~16.04.1-Ubuntu SMP Tue Jan 29 18:03:48 UTC
2019 x86_64 x86_64 x86_64 GNU/Linux
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to
17 matches
Mail list logo
