Constant ixnas vfs module errors that set_native_dos_mode operation is not permitted

[parth]

Hi All,

I wanted to get to the bottom of some strange behaviour in my TrueNAS Core 13.0-U2 system. I have a couple of large Samba shares configured here and all seems to be working fine. But my /var/log/samba4/log.smbd file is constantly flooded with the following errors:

Code:

[2022/09/28 19:04:04.495591,  1] ../../source3/modules/vfs_ixnas.c:134(ixnas_set_native_dosmode)
  ixnas_set_native_dosmode: Setting dosmode failed for /path/to/some/shared/file.pdf: Operation not permitted

I think this may have something to do with some samba misconfiguration on my part. I did not find much on the vfs_ixnas module online or elsewhere in the forums. So I'm seeking the help of the TrueNAS and Samba experts here to help me get to the bottom of this. Any help would be greatly appreciated.

My share configuration is as follows:

Code:

# Global parameters
[global]
    bind interfaces only = Yes
    disable spoolss = Yes
    dns proxy = No
    enable web service discovery = Yes
    kernel change notify = No
    load printers = No
    logging = file
    max log size = 5120
    nsupdate command = /usr/local/bin/samba-nsupdate -g
    registry shares = Yes
    restrict anonymous = 2
    server multi channel support = No
    server role = standalone server
    server string = TrueNAS Server
    unix extensions = No
    idmap config *: range = 90000001-100000000
    fruit:nfs_aces = No
    idmap config * : backend = tdb
    directory name cache size = 0
    dos filemode = Yes

[MyShare]
    case sensitive = Yes
    comment = My Documents
    ea support = No
    inherit owner = windows and unix
    inherit permissions = Yes
    kernel share modes = No
    path = /mnt/tank/myshare
    posix locking = No
    read only = No
    smbd max xattr size = 2097152
    vfs objects = fruit streams_xattr shadow_copy_zfs ixnas zfs_core aio_fbsd
    fruit:resource = stream
    fruit:metadata = stream
    nfs4:chown = true

All the files in the share are set up to be owned by the root user and the wheel group (hence the inherit owner and inherit permissions in the configuration above). There are 2 users that access these shares for whom permissions to do so are provided via appopriate ACLs - 1 user has complete read/write access and the other has readonly access.

 

[anodos]

Hi All,

I wanted to get to the bottom of some strange behaviour in my TrueNAS Core 13.0-U2 system. I have a couple of large Samba shares configured here and all seems to be working fine. But my /var/log/samba4/log.smbd file is constantly flooded with the following errors:

Code:

[2022/09/28 19:04:04.495591,  1] ../../source3/modules/vfs_ixnas.c:134(ixnas_set_native_dosmode)
  ixnas_set_native_dosmode: Setting dosmode failed for /path/to/some/shared/file.pdf: Operation not permitted

I think this may have something to do with some samba misconfiguration on my part. I did not find much on the vfs_ixnas module online or elsewhere in the forums. So I'm seeking the help of the TrueNAS and Samba experts here to help me get to the bottom of this. Any help would be greatly appreciated.

My share configuration is as follows:

Code:

[MyShare]
    case sensitive = Yes
    comment = My Documents
    ea support = No
    inherit owner = windows and unix
    inherit permissions = Yes
    kernel share modes = No
    path = /mnt/tank/myshare
    posix locking = No
    read only = No
    smbd max xattr size = 2097152
    vfs objects = fruit streams_xattr shadow_copy_zfs ixnas zfs_core aio_fbsd
    fruit:resource = stream
    fruit:metadata = stream
    nfs4:chown = true

All the files in the share are set up to be owned by the root user and the wheel group (hence the inherit owner and inherit permissions in the configuration above). There are 2 users that access these shares for whom permissions to do so are provided via appopriate ACLs - 1 user has complete read/write access and the other has readonly access.

Can you PM me a debug please?

 

[anodos]

If I were to hazard a guess, the client may be trying to set PDF as a reparse point. If you can readily reproduce. I am very interesting in investigating what your client is doing.

 

[parth]

Hi @anodos, thanks for the response.

Can you PM me a debug please?

I'm sorry I don't readily know how to do so. Do you want me to change the logging level on the server side and provide more detailed logs. Basically my current logs contain several messages every minute of the kind I posted earlier.

If I were to hazard a guess, the client may be trying to set PDF as a reparse point. If you can readily reproduce. I am very interesting in investigating what your client is doing.

Some of the clients are Linux "servers" that are downloading and storing files onto the NAS server where the Samba share is mounted using cifs. These connect as the user with write permissions.
Other clients are "users" that connect to the share on Windows as the readonly user to view the saved files.

The cifs mount options for the Linux servers are:

Code:

//nas-host/MyShare /path/to/mount/point cifs rw,relatime,vers=default,cache=strict,username=privatecircle,domain=,uid=1000,forceuid,gid=1000,forcegid,addr=192.168.12.120,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1 0 0

EDIT: I have verified that the log line is printed whenever there is a write to a file into the CIFS mounted share from the Linux "servers".

 

[anodos]

I'm sorry I don't readily know how to do so.

system->advanced->save debug

What version of linux is this (distro and kernel)?

 

[parth]

The Linux server is using Ubuntu 16.04 with mount.cifs version 6.4

Code:

user@host:~$ mount.cifs --version
mount.cifs version: 6.4
user@host:~$ lsb_release -a
Distributor ID:    Ubuntu
Description:    Ubuntu 16.04.7 LTS
Release:    16.04
Codename:    xenial

However, I've tested the same on Ubuntu 20.04 mounting the share via fuse (with Nautilus) or directly using mount -t cifs as with the current setup and I still get the same error log. Note that this happens only when a file is created. There is no log if I delete a file, append to a file or create / delete a directory.

 

[anodos]

Can't reproduce with my Linux client. Can you get a packet capture and send to me via PM?

 

[parth]

Could the issue have something to do with the dos filemode = Yes global configuration setting. I don't really know the implication of changing this so I haven't tested modifying it manually to dos filemode = Yes.

 

[anodos]

Without seeing any additional info from your server, the best I can tell you is:
1. remove all auxiliary parameters
2. specify `noperm` in your mount.cifs options

 

[parth]

Can't reproduce with my Linux client. Can you get a packet capture and send to me via PM?

The forum has become basically unusable for me. 502 errors all over the place. I'm having to refresh 10-15 times just to be able to view this page itself or reply to a post. I've tried uploading the debug tarball and the packet capture but that seems impossible at the moment. If you could PM me your email address, I could send them over directly maybe.

In the meantime, this is a summary of what I know so far.

• The share is working as expected. Files are getting created with the correct ownership and permissions and accessing the files on Windows or Linux works just fine.
• The only issue is the log lines described above which are flooding the logs for every file created within the share.
• Creating a file directly within the dataset (not over Samba) does not cause this issue.
• Appending to an existing file, deleting a file, creating a directory or deleting a directory does not cause any problems whatsoever
• The choice of client does not matter. I always get these logs when creating a file on the Samba share whether connected via Windows File Explorer, Nautilus on Ubuntu or a cifs mounted share
• There is 1 tiny (and very strange) difference in behaviour between accessing on Windows vs cifs mount. Accessing the share on Windows File Explorer, the log line is not produced for files created at the top level of the folder hierarchy but only for files created within subfolders. For the Linux system, the log line comes for every file write regardless of its file path within the share. Looking at the getfacl output the only difference I can see between the top level shared folder and its subfolders and files is the presence of a I flag at the end which as I understand it stands for inherited permissions.
• The issue is not present if "inherit owner" is not provided in the share configuration

I can also provide minimal reproducible steps resulting in this issue on TrueNAS Core 13.1-U2:

• Create a dataset with "Share Type" as Generic
• Create a new user
• Setup the ACLs based on "Restricted" preset on the new dataset such that the owner and group are root and wheel (the defaults) and the new user has "Full Control" on the dataset.
• Create a Samba share pointing to this dataset with default share permissions adding "inherit owner = yes" in the auxiliary parameters
• Mount the share via CIFS connecting as the new user and create a file. The log line should show up in /var/log/samba4/log.smbd

 

[parth]

Without seeing any additional info from your server, the best I can tell you is:
1. remove all auxiliary parameters
2. specify `noperm` in your mount.cifs options

Tried this. Made no difference.

 

[parth]

@anodos: Thanks for your all your help here as well as over email. I see you've raised a PR to change the log level of these messages from WARNING to DEBUG which would solve this issue.

I'll wait for the next release cycle for this issue to be fixed. In the meantime, since this is an annoyance more than a critical bug, I'm marking this issue as closed.

 

[anodos]

Yes, I reviewed your auxiliary parameters again. Since you're forcing owner inheritance from parent directory, the initial chflags(2) call is failing with EPERM because you're not the file owner anymore. We allow overriding the OS permissions in some cases via having process seteuid to privileged user. I reworked the log messages so that we don't log on the first failure (e.g. EPERM from non-root).