Unfortunately I don't feel like I have enough understanding of why
things are working for you given the versions you are dealing with. The
whole thing seems like a complex compatibility matrix of client version,
server version, and negotiated SMB protocol version. I've seen enough
code changes and
I kept digging into my specific issue, and now have to add a 4th
dimension to the matrix of variables to consider that can affect modtime
preservation: Samba configuration values. Here are the details.
For my issue, modtimes are not preserved on Synology devices due to the
Synology's default SMB A
Thanks for sharing that. Your cifs-utils is the same that I have on an
ubuntu 22 VM, which shows the issue with a server running an earlier
version of Samba (4.7.x) and a later version. I unfortunately don't
readily have a VM with 4.8.x readily available, but the brittleness of
file modtime preserv
Interesting. Can you run "apt-get -s install cifs-utils" on your client
to see what version of cifs-utils you have installed?
--
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/2007055
Title:
Awesome, thanks for the help. Could you run samba -V on the server to
see the samba version running there?
And then on the client, could you run:
cat /proc/mounts
and find the line with your share to see what version of the SMB
protocol it ended up using?
(It'll be a line like:
//10.0.234.59/sa
Oooh, now it gets exciting. You mentioned you were using the RN214,
which runs Netgear ReadyNAS, which appears to be based on a pretty old
version of Debian. So I fired up an Ubuntu 15 VM and created an SMB
share on it. The bug reproduces there...
That gives us a server environment where we can fu
So just to make sure I was clear, "fixing" the client to send cleaner
messages does avoid the problem. But (imho) the real issue is on the
server, since other servers can deal with the less clean messages just
fine, and there's nothing wrong (again, imho) with the less clean
messages.
Is that unam
Here is a comparison of the network captures between an Ubuntu Server
23.10 client and Ubuntu Server 22.04.3 LTS client. The difference noted
is consistent with when the bug reproduces - that is, Windows 10, Ubuntu
Server 23.10, and latest arch all have the SetInfo by itself and the bug
does not re
So I've got more investigation results. I no longer think it is the Last
Access difference that is relevant, but rather differences in the SMB
request pattern from the client that triggers buggy server behavior.
First, the updated results:
1. To reproduce, The file must be non-empty. The issue do
So I encountered this recently as well. I've got some strong evidence
that at least part of the problem is the SMB *server*, specifically a
Synology NAS.
We are migrating from a TrueNAS to Synology, and I noticed the timestamp
issue after rsync'ing files from an Ubuntu 22.04 client. I simplified b
10 matches
Mail list logo
