Permission denied on .dot files in CIFS share

Phiolin

Cadet
Joined
Jul 8, 2023
Messages
4
I've just encountered a strange issue where I can create, but not modify, any .dot files on my CIFS shares from a Linux machine.
Running TrueNAS-13.0-U5.1, exporting several CIFS shares to a Linux (Proxmox) server.

Basically it goes like this:

$ touch /mnt/volume/.test
$ echo test > /mnt/volume/.test
$ echo test2 > /mnt/volume/.test
-bash: /mnt/volume/.test: Permission denied
So I can touch the file, then write something to it, but then when I try to write a second time, it fails and I get "permission denied" every time.
I can then proceed to rm -f the file, which will work fine as well.

What might be the issue that prevents me from writing to a .dot file a second time, but let's me delete it just fine?
This is just a .dot file issue. Normal files that don't start with the "." are working fine.
ACLs and Share permissions all looking good to me - I can perform the same operations natively on the TrueNas server without any issue. It just occurs when doing it via a CIFS mount.
Mount parameters are fairly standard (from /etc/fstab):
//10.0.0.5/share /mnt/share cifs noauto,x-systemd.automount,x-systemd.mount-timeout=30,_netdev,credentials=/etc/credentials.cred,dir_mode=0750,nosuid,nodev,noexec,noperm,uid=100033 0 0

Any hint on what else I can check?
I think this started occuring recently, because I noticed it when trying to update my Nextcloud instance. The updater suddenly fails writing it's .step files, which worked perfectly fine when I updated it last time - though that might've been a couple weeks ago.
 

Attachments

  • share_settings.png
    share_settings.png
    58.4 KB · Views: 52

NickF

Guru
Joined
Jun 12, 2014
Messages
763
Take a look at the log file in /var/log/samba4/log.smbd
It should help you on your way. You can post the output here if you want some help.

Also, an even simpler place to start:
What are your share ACLS? What are your filesystem ACLS?
 

Phiolin

Cadet
Joined
Jul 8, 2023
Messages
4
Unfortunately there is nothing in log.smbd to work with, can't see any related messages, at least not in the default log level.

The share is mounted with the user that owns the files, so @owner permissions would apply.

Share ACLs:
1689082818845.png


FS ACLs:
1689083321033.png

1689083043487.png
 

Attachments

  • 1689083015787.png
    1689083015787.png
    108.2 KB · Views: 64

Phiolin

Cadet
Joined
Jul 8, 2023
Messages
4
I switched up the log level to "Full" and this relates to consecutive access to the files:

[2023/07/11 15:51:55.928674, 2] ../../source3/smbd/open.c:1686(open_file)
andreas opened file .test read=No write=No (numopen=3)
[2023/07/11 15:51:55.929249, 2] ../../source3/smbd/close.c:837(close_normal_file)
andreas closed file .test (numopen=1) NT_STATUS_OK
[2023/07/11 15:51:55.930266, 3] ../../source3/smbd/smb2_server.c:3956(smbd_smb2_request_error_ex)
smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_ACCESS_DENIED] || at ../../source3/smbd/smb2_create.c:337

And this happens when I create a completely new file:

$ echo test > .test
[2023/07/11 15:54:46.106916, 2] ../../source3/smbd/open.c:1686(open_file)
andreas opened file .test read=No write=Yes (numopen=3)
[2023/07/11 15:54:46.130096, 3] ../../source3/smbd/trans2.c:9113(smbd_do_setfilepathinfo)
smbd_do_setfilepathinfo: .test (fnum 2127776050) info_level=1020 totdata=8
[2023/07/11 15:54:46.131114, 2] ../../source3/smbd/open.c:1686(open_file)
andreas opened file .test read=No write=No (numopen=4)
[2023/07/11 15:54:46.131442, 3] ../../source3/smbd/trans2.c:9113(smbd_do_setfilepathinfo)
smbd_do_setfilepathinfo: .test (fnum 2632155037) info_level=1004 totdata=40
[2023/07/11 15:54:46.131921, 2] ../../source3/smbd/close.c:837(close_normal_file)
andreas closed file .test (numopen=2) NT_STATUS_OK
[2023/07/11 15:54:46.132982, 3] ../../source3/smbd/smb2_write.c:220(smb2_write_complete_internal)
smb2: fnum 2127776050, file .test, length=5 offset=0 wrote=5

And try to write to it again:
$ echo test > .test
-bash: .test: Permission denied
[2023/07/11 15:54:47.141027, 2] ../../source3/smbd/close.c:837(close_normal_file)
andreas closed file .test (numopen=1) NT_STATUS_OK
[2023/07/11 15:54:48.558810, 2] ../../source3/smbd/open.c:1686(open_file)
andreas opened file .test read=No write=No (numopen=3)
[2023/07/11 15:54:48.559323, 2] ../../source3/smbd/close.c:837(close_normal_file)
andreas closed file .test (numopen=1) NT_STATUS_OK
[2023/07/11 15:54:48.560114, 3] ../../source3/smbd/smb2_server.c:3956(smbd_smb2_request_error_ex)
smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_ACCESS_DENIED] || at ../../source3/smbd/smb2_create.c:337

The only thing I can spot is
"opened file .test read=No write=No"
which I'm unsure but shouldn't it actually say ... Yes?
 

NickF

Guru
Joined
Jun 12, 2014
Messages
763
You have "everyone" set to modify. When you are doing your testing, are you authenticated to the TrueNAS, or are you using a the guest account?
 

Phiolin

Cadet
Joined
Jul 8, 2023
Messages
4
Yes, I'm authenticating with the owner user.
I don't really see a permission issue here. I can work, modify, rewrite all files just fine as much as I want.
It is just files that start with the "." which I'm having issues with and only if I try to write to them a second time. Not sure if there is any special handling with "."/hidden files on Samba in TrueNas which isn't immediately obvious in the share config?
 
Top