Faulty timestamps

[Anuskuss]

It's not the end of the world but I do like to have accurate timestamps. Not even Samba got it right either. I'll try to illustrate what I mean (let's assume every step happens one hour apart):

1. Create file in server

Server

	Samba	Samba unix	ksmbd
Access	00:00 ✔️	00:00 ✔️	00:00 ✔️
Modify	00:00 ✔️	00:00 ✔️	00:00 ✔️
Change	00:00 ✔️	00:00 ✔️	00:00 ✔️
Birth	⚠️	⚠️	00:00 ✔️

Client

	Samba	Samba unix	ksmbd
Access	00:00 ✔️	00:00 ✔️	00:00 ✔️
Modify	00:00 ✔️	00:00 ✔️	00:00 ✔️
Change	00:00 ✔️	00:00 ✔️	00:00 ✔️
Birth	00:00 ✔️	⚠️	00:00 ✔️

Windows

	Samba	Samba unix	ksmbd
Created	00:00 ✔️	00:00 ✔️	00:00 ✔️
Modified	00:00 ✔️	00:00 ✔️	00:00 ✔️
Accessed	00:00 ✔️	00:00 ✔️	00:00 ✔️

2. Modify file in client

Server

	Samba	Samba unix	ksmbd
Access	00:00	00:00	00:00
Modify	01:00 ✔️	01:00 ✔️	01:00 ✔️
Change	01:00 ✔️	01:00 ✔️	01:00 ✔️
Birth	⚠️	⚠️	00:00 ✔️

Client

	Samba	Samba unix	ksmbd
Access	01:00	01:00	01:00
Modify	01:00 ✔️	01:00 ✔️	01:00 ✔️
Change	01:00 ✔️	01:00 ✔️	01:00 ✔️
Birth	01:00 ⚠️	⚠️	00:00 ✔️

Windows

	Samba	Samba unix	ksmbd
Created	00:00 ✔️	00:00 ✔️	01:00 ❌
Modified	01:00 ✔️	01:00 ✔️	01:00 ✔️
Accessed	01:00	00:00	00:00

3. Modify file in client again

Server

	Samba	Samba unix	ksmbd
Access	02:00 ✔️	02:00 ✔️	02:00 ✔️
Modify	02:01 ✔️	02:01 ✔️	02:01 ✔️
Change	02:01 ✔️	02:01 ✔️	02:01 ✔️
Birth	⚠️	⚠️	00:00 ✔️

Client

	Samba	Samba unix	ksmbd
Access	02:01 ✔️	02:01 ✔️	02:01 ✔️
Modify	02:01 ✔️	02:01 ✔️	02:01 ✔️
Change	02:01 ✔️	02:01 ✔️	02:01 ✔️
Birth	00:00 ✔️	⚠️	00:00 ✔️

Windows

	Samba	Samba unix	ksmbd
Created	02:00 ❌	02:00 ❌	02:01 ❌
Modified	02:01 ✔️	02:01 ✔️	02:00 ✔️
Accessed	02:00 ✔️	02:00 ✔️	02:00 ✔️

TLDR: Don't change the created timestamp (inside the extended file attributes).

[namjaejeon]

@Anuskuss Thanks for your report:) This result is from SMB2 connection ? or SMB1 ?

[Anuskuss]

SMB3 actually.
Back when I started with Samba I enabled store dos attributes because I like knowing when files were created and Linux didn't store that timestamp back then (or my filesystem didn't support it I don't know). But now that there's Birth couldn't you just map the timestamps as is? I don't care about the other DOS attributes (other than hidden but that has been taken care of via hide dot files in Samba) so I personally don't see a point in utilizing extended attributes at all
(as a matter of fact I'm planning on writing a script which decodes user.DOSATTRIB and sets the timestamps accordingly).

[namjaejeon]

Okay, Let me check it.
BTW, I have a question.

Could you please explain what is meaning "Server", "Client" and "Windows" ?

2. Modify file in client
Server
Client
Windows

[Anuskuss]

Server: A Debian machine hosting ksmbd
Client: An Arch machine accessing the server (mount -o username=$user,password=$pass //$server/$share /mnt)
Windows: A Windows 10 VM accessing the server (net use Z: \\$server\$share /user:$user $pass)

[namjaejeon]

@Anuskuss Okay, You provided timestamp difference to me for Client, Server and Windows.

For Client and Windows, You compared the difference in timestamp of files against each server through the mount directory. But what is the timestamp for the servers? Does it just mean the timestamp of the local file in the share of server?

[Anuskuss]

Does it just mean the timestamp of the local file in the share of server?

Yep. I'm stating the same file once on the server (where the file is stores) and once on the client (where the share is mounted) and the timestamps don't always match.

[namjaejeon]

Hm.. I can not reproduce this issue. Windows also shows the same creation time as Linux. Can you give your ksmbd information ?

1. ksmbd(out of tree? or ksmbd in linux kernel), ksmbd-tools version.
2. show me your ksmbd.conf contents.
3. what local filesystem for share directory? ext4 or ?

[Anuskuss]

Seems like ksmbd (and Samba) ignores the birth time (btime) and just uses the oldest timestamp it knows about (atime, ctime, mtime).

1. Master
2. Nothing interesting.
3. ZFS

Run this:

file=/path_to_share/testfile && touch $file && sleep 2 && echo 1 > $file && sleep 2 && chmod u+x $file && sleep 2 && cat $file > /dev/null && stat $file

In this case, the oldest timestamp is going to be mtime. So in Windows it will report the creation time (lets assume you ran this at midnight exactly) as 00:00:02 instead of 00:00:00.

[namjaejeon]

Hm... I can not reproduce this issue, Sorry. Can you try to reproduce it using ext4 ? I don't know that ZFS support xattr(extended attribute). because ksmbd store creation time to xattr space.

[namjaejeon]

2. Nothing interesting.

I was wondering you turn "store dos attributes" off in ksmbd.conf.

man ksmbd.conf
store dos attributes (S)
Store DOS attributes using xattr and then use them in the DOS-to-UNIX-mapping of
permissions.

          Default: store dos attributes = yes

[Anuskuss]

I was wondering you turn "store dos attributes" off in ksmbd.conf.

Yeah it's off. If I turn it on it obviously works but I'm trying to get away from extended attributes (most of my SMB traffic is actually happening between Linux machines nowadays and the Windows machines/smartphones that do use it don't care too much about accurate attributes).

Can you try to reproduce it using ext4 ?

I can try that but it might take a few days.

[Anuskuss]

Sorry for the wait.
Using EXT4 doesn't change the outcome. The btime timestamp is simply ignored by ksmbd and Samba. I've noticed however that Samba generates the Creation time from the oldest timestamp available (sans btime) while ksmbd seems to only care about ctime.
I don't understand how you can't reproduce this. Running that code snippet above on your Linux server and then reading the timestamps on Windows client (with somethink like Attribute Changer) immediately shows that the Creation time is younger than the Modification time.

P.S. I was reusing my Samba smb.conf and noticed that the server would sometimes crash. Looks like it's releated to ea support = yes.

[ksmbd-worker/675779]: ERROR: SRVSVC: unsupported INVOKE method 21