On Sat, Sep 28, 2024 at 6:49 AM Steve French <smfrench@xxxxxxxxx> wrote: > > I noticed that support for special file support for ksmbd has improved > with the recent patches e.g. but symlink can not be reported see below > (in this example, I am mounting with "linux" mount option but file > types are reported ok without "linux" as well): This is not a new issue. symlink support in ksmbd was removed on upstream, So smb2_create for symlink files to return STATUS_ACCESS_DENIED. Work is in progress to add symlink support. We have to wait. Aside from that, what's strange is... What is "linux" option? ksmbd refuses to open symlink regardless of "linux" option of cifs. Why does cifs.ko show differences depending on that option? Thanks. > > root@smfrench-ThinkPad-P52:/shares/test# ls /mnt2 -l > ls: /mnt2/symlinktofile: Permission denied > total 8192 > -rw-r--r-- 1 root root 0 Sep 27 16:37 block1 > -r--r--r-- 1 root root 0 Sep 27 16:37 block2-mode-0444 > -rw-r--r-- 1 root root 0 Sep 27 16:36 char1 > -r--r--r-- 1 root root 0 Sep 27 16:37 char2-mode-0444 > -rw-r--r-- 1 smfrench root 0 Sep 27 16:37 char3-owner-smfrench > -rw-r--r-- 1 root root 0 Sep 27 16:36 fifo > -rw-r--r-- 1 root root 0 Sep 27 16:38 file > -rwxrwxrwx 1 root root 4 Sep 27 16:38 symlinktofile > > and > > # stat /mnt2/symlinktofile > stat: cannot statx '/mnt2/symlinktofile': Permission denied > > Locally the symlink looks like this on the server: > $ stat /shares/test/symlinktofile > File: /shares/test/symlinktofile -> file > Size: 4 Blocks: 0 IO Block: 4096 symbolic link > Device: 259,6 Inode: 268436173 Links: 1 > Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root) > > A few at SDC also reminded that it is best to report server side > symlink with the default Windows format (reparse point for Windows > symlink). > > Any ideas? > > > > -- > Thanks, > > Steve
