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
Is there anything anyone would want to know (or must be told), so we can
anticipate these kinds of issues with Linux/the
Kernel/Mint/ReadyNAS/NetGear/Ubuntu/Debian/Synology/SAMBA/cifs in the
future and prevent another regression ruining all my or any other users'
timestamps next time we run 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
Output of apt-get -s install cifs-utils:
cifs-utils is already the newest version (2:6.14-1ubuntu0.1).
Same for SAMBA:
samba is already the newest version (2:4.15.13+dfsg-0ubuntu1.5).
Hope that helps.
--
You received this bug notification because you are a member of Kernel
Packages, which is
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:
cat /proc/mounts gives me something like:
//rn214/user /media/rn214/user cifs
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:
OK, ran the script on my end, result was:
Copy complete; sleeping 10 seconds before stat
Source modtime: 2020-01-01 12:34:56.0 +0100
Target modtime: 2020-01-01 12:34:56.0 +0100
PASS: Modtime preserved
Client:
Kernel Linux 6.5.0-14-generic
Operating System: Linux Mint 21.2
SAMBA:
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
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
> I no longer think it is the Last Access difference that is relevant,
> but rather differences in the SMB request pattern
> In Ubuntu 20 and Ubuntu 22, the packet that sets the file info has that
> request "wrapped'
> by create file/close file SMB messages. In Ubuntu 23.10 and arch, these
>
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
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
@Nicholas Neumann: Interesting! So the only difference is, that Windows
clients do not specify the "Last Access" attribute. So in case of a
Windows client, you expect and see a modification date of Nov 22, 2023
13:15:09 on the NAS, for the Linux client (which transmits the "Last
Access"
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
Hi Andreas!
Thanks for taking care. Of course I can not say 100% that the behaviour
will never ever happen again with 6.2.0-32, because it was something
like 4/10 on 5.15.0-82 with no clear pattern but I'll update this ticket
if I have any news.
Perhaps you/someone can backport the fix from
Thanks for your last update.
cifs is indeed provided by the kernel, and mounted via mount.cifs from
cifs-utils. Although similar in nature, this is not samba code. All of
this discussion is pointing at something in the kernel, so I'm switching
the bug task from samba to linux (which is the
18 matches
Mail list logo
