Your message dated Mon, 18 Feb 2019 21:09:53 +0100 with message-id <cafx5sbx0cgkgbrx6fgp_tn1aj3vwxrk-ud6o0doxzez0gdz...@mail.gmail.com> and subject line Re: Reproducing " samba: cp and cat return an endless stream of 0s when reading a file on a samba share" has caused the Debian Bug report #803941, regarding samba: cp and cat return an endless stream of 0s when reading a file on a samba share to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 803941: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803941 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: samba Version: 2:4.1.20+dfsg-1 Severity: important Dear Maintainer, * What led up to the situation? Recently I noticed that trying to copy or otherwise manipulate files on my nas box running Debian Stable would seemingly hang in some circumstances, such as when using cp or cat, but not when using rsync or directly running hexdump on a file. Examining the destination file when using cp showed that it was in fact growing endlessly, even if the source file was only a few bytes. Running cat on any file on the samba mount would also seemingly hang, and piping the output through hexdump showed it was spewing 0s (using hexdump directly will not see this problem as it only reads the expected filesize reported by stat()) * What exactly did you do (or not do) that was effective (or ineffective)? 1. Create a samba share on a Debian system 2. Mount that share on another system 3. On the client, cd into the mounted share and run: echo foo > bar cat bar | hexdump -Cv * What was the outcome of this action? 00000000 66 6f 6f 0a 00 00 00 00 00 00 00 00 00 00 00 00 |foo.............| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| ... * What outcome did you expect instead? 00000000 66 6f 6f 0a |foo.| 00000004 This seems to be a server issue, as attaching strace to smbd while running the above command produced this: pread(32, "foo\n", 65536, 0) = 4 writev(37, [{"foo\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 65536}], 1) = 65536 pread(32, "", 65536, 65536) = 0 writev(37, [{"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 65536}], 1) = 65536 poll([{fd=11, events=POLLIN|POLLHUP}, {fd=7, events=POLLIN|POLLHUP}, {fd=37, events=POLLIN|POLLHUP}], 3, 59577) = 1 ([{fd=37, revents=POLLIN}]) poll([{fd=37, events=POLLIN|POLLHUP}], 1, 0) = 1 ([{fd=37, revents=POLLIN}]) read(37, "\0\0\0;", 4) = 4 read(37, "\377SMB.\0\0\0\0\0\1\300\0\0\0\0\0\0\0\0\0\0\0\0\303\224\0A\302\215\321\31"..., 59) = 59 writev(37, [{"\0\2\0;\377SMB.\0\0\0\0\200\3\310\0\0\0\0\0\0\0\0\0\0\0\0\303\224\0A"..., 63}], 1) = 63 pread(32, "", 65536, 131072) = 0 writev(37, [{"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 65536}], 1) = 65536 pread(32, "", 65536, 196608) = 0 writev(37, [{"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 65536}], 1) = 65536 poll([{fd=11, events=POLLIN|POLLHUP}, {fd=7, events=POLLIN|POLLHUP}, {fd=37, events=POLLIN|POLLHUP}], 3, 59556) = 1 ([{fd=37, revents=POLLIN}]) poll([{fd=37, events=POLLIN|POLLHUP}], 1, 0) = 1 ([{fd=37, revents=POLLIN}]) read(37, "\0\0\0;", 4) = 4 ... As you can see, the pread call is behaving correctly, but the daemon ignored the return value and appears to be using the total buffer size instead (64K bytes are sent to the client, offset increases by 64K each call, end of file is being ignored). This bug is confirmed to be currently present in: Debian stable (2:4.1.17+dfsg-2) Debian testing (2:4.1.17+dfsg-4) Debian unstable (2:4.1.20+dfsg-1) -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages samba depends on: ii adduser 3.113+nmu3 ii dpkg 1.17.25 ii libasn1-8-heimdal 1.6~rc2+dfsg-9 ii libbsd0 0.7.0-2 ii libc6 2.19-18 ii libcomerr2 1.42.12-1.1 ii libhdb9-heimdal [heimdal-hdb-api-8] 1.6~rc2+dfsg-9 ii libkdc2-heimdal 1.6~rc2+dfsg-9 ii libkrb5-26-heimdal 1.6~rc2+dfsg-9 ii libldb1 2:1.1.21-1 ii libpam-modules 1.1.8-3.1 ii libpam-runtime 1.1.8-3.1 ii libpopt0 1.16-10 ii libpython2.7 2.7.9-2 ii libroken18-heimdal 1.6~rc2+dfsg-9 ii libtalloc2 2.1.1-2 ii libtdb1 1.3.1-1 ii libtevent0 0.9.21-1 ii lsb-base 4.1+Debian13+nmu1 ii procps 2:3.3.9-9 ii python 2.7.9-1 ii python-dnspython 1.12.0-1 ii python-ntdb 1.0-5 ii python-samba 2:4.1.20+dfsg-1 pn python2.7:any <none> ii samba-common 2:4.1.20+dfsg-1 ii samba-common-bin 2:4.1.20+dfsg-1 ii samba-dsdb-modules 2:4.1.20+dfsg-1 ii samba-libs 2:4.1.20+dfsg-1 ii tdb-tools 1.3.1-1 ii update-inetd 4.43 Versions of packages samba recommends: pn attr <none> ii logrotate 3.8.7-1+b1 pn samba-vfs-modules <none> Versions of packages samba suggests: pn bind9 <none> pn bind9utils <none> pn ctdb <none> pn ldb-tools <none> ii ntp 1:4.2.6.p5+dfsg-7+deb8u1 pn smbldap-tools <none> pn winbind <none> -- debconf information: samba-common/title: samba/run_mode: daemons
--- End Message ---
--- Begin Message ---Version: 2:4.5.16+dfsg-1 Le lun. 18 févr. 2019 à 21:04, Ian Munsie <[email protected]> a écrit : > > This looks to be fixed :) > > Server running Debian Stretch with Samba 2:4.5.16+dfsg-1 and client > running Debian Stretch with cifs-utils 2:6.7-1: > > [N] ian@draal~> mount /mnt/nas > [I] ian@draal~> cd /mnt/nas/ > [I] ian@draal/m/nas> echo foo > bar > [I] ian@draal/m/nas> cat bar | hexdump -Cv > 00000000 66 6f 6f 0a |foo.| > 00000004 Marking fixed and closing. Thanks for your feedback. Regards -- Mathieu Parent
--- End Message ---
