SMB | Unauthorized file writing on "random" files

[Hibiki]

Hi all!

I got an issue on TrueNAS CORE (TrueNAS-12.0-U5.1) by copying files from a Windows 10 Pro client by using the SMB service:

1. The authorizations are correctly set as I can copy / delete / modify mostly all the files in a share
2. However, on several files (up to now, I noticed this issue on .cbz, .exe and .pdf files but not for all these filetypes), the copy from Windows 10 client to the share failed with the following message: "You need to have the administrator right for copying this file" (or something approaching as I translate it into english...). I click on continue (with the shield icon) and the copy failed with "Access to folder denied / You do not have the authorization to copy files at this location through the network"
3. I tried on several shares with different authorization and it failed...
4. I also formatted my Windows 10 client and the issue is still present...
5. If I'm using the FTP, I can copy the file... Once the file is copied, I can rename it, move it accross the share and copy it on the Windows 10 client. And I can copy this file back to the share without any issue anymore (!!).

I never remembered experienced such issue on FreeNAS but I copied files with the root login on SMB service so... It may not be comparable.

SMB parameters are per default ("Enable SMB1 support" unticked) but "Local Master" is ticked and in the "Auxiliary Parameters" field, I have "wins support = Yes" and "domain master = Yes" because I have a lot of issues to reach the shares through the NetBios name.
However this issue is present if I'm using the IP address or the NetBios name of the server.

In the var/log/samba4/log.smbd, I got the following entry when a file failed to copy:

Code:

[2021/09/18 17:34:09.314426,  2] ../../source3/auth/auth.c:347(auth_check_ntlm_password)
  check_ntlm_password:  Authentication for user [xxx@gmail.com] -> [xxx@gmail.com] FAILED with error NT_STATUS_NO_SUCH_USER, authoritative=1
[2021/09/18 17:34:09.314448,  2] ../../auth/auth_log.c:653(log_authentication_event_human_readable)
  Auth: [SMB2,(null)] user [MicrosoftAccount]\[xxx@gmail.com] at [Sat, 18 Sep 2021 17:34:09.314441 CEST] with [NTLMv2] status [NT_STATUS_NO_SUCH_USER] workstation [APOLLON] remote host [ipv4:10.0.0.88:54793] mapped to [MicrosoftAccount]\[xxx@gmail.com]. local host [ipv4:10.0.0.5:445] 

When I started a copy (that succeeded) on the same share, I got, in the same log:

Code:

[2021/09/18 17:47:00.771481,  2] ../../source3/smbd/service.c:868(make_connection_snum)
  apollon (ipv4:10.0.0.88:63531) connect to service Library initially as user hibiki (uid=1000, gid=1000) (pid 8960)

I do not know what to do as it is random... But once a file is "locked" for the initial copy, it fails again on reboot and so on...

What can I do? Please help

 

[Hibiki]

I noticed something today about pdf files: the "blocked" files are downloaded from websites such as bank accounts or bills (e.g. Amazon).
I tried to compare a PDF file "unlocked" and a "locked" one and I discover something weird:
If the file has the attribute Read-only in the Windows 10 client, the copy failed.
If I remove the attribute Read-Only in the Windows 10 client, the copy succeeds then

Then I copy a .sha512 file with the read-only attribute and the copy... succeeds too...
I did the same with a jpg file with the read-only attribute and it worked..

I did the same with a PDF with an issue previously and it failed... I removed the Read-Only attribute and the copy of the PDF copy worked...

Now with a PDF without particular issue : I generated it from PDF-XChange Editor with a jpg as source file.
With the read-only attribute, it... works... What the hell?! Thus it is not only dependent on the read-only attribute

I did a last operation: I copied a PDF copy file by removing the read-only attribute on the share then I moved it again in the source folder and I applied the Read-Only attribute. I tried to copy it again from Windows 10 client to share with this read-only attribute and it failed too...
So it seems that even copied on the share, something is still blocking for redoing the same activity...

By using a user with the same level of authorization as me, the same issue applies...