Bug 15409 - dangling symlinks in filesystem cause NT_STATUS_OBJECT_NAME_NOT_FOUND for clients
Summary: dangling symlinks in filesystem cause NT_STATUS_OBJECT_NAME_NOT_FOUND for cli...
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.18.3
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Jeremy Allison
QA Contact: Samba QA Contact
: 15489 (view as bug list)
Depends on:
Reported: 2023-06-30 10:57 UTC by Björn Jacke
Modified: 2024-01-30 19:59 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Björn Jacke 2023-06-30 10:57:43 UTC
This is the content of a share:

lrwxrwxrwx 1 bjacke users 6 30. Jun 12:25  YY -> YY.txt
-rwxr--r-- 1 bjacke users 0 30. Jun 12:25 'YY (2)'

Then I connect with smbclient...:

smb: \test2\> dir
  .                                   D        0  Fri Jun 30 12:55:15 2023
  ..                                  D        0  Fri Jun 30 11:40:43 2023
  YY (2)                              A        0  Fri Jun 30 12:25:22 2023

		256917828 blocks of size 1024. 82437832 blocks available

okay, so far, this is expected because the symlink is dangling. But then:

smb: \test2\> rename YY (2) YY
NT_STATUS_OBJECT_NAME_NOT_FOUND renaming files \test2\YY -> \test2\(2) 

This is not expected. Tested the same with 4.16, there the rename operation is successfull and the dangling symlink is replaced by the rename operation.
Comment 1 Jeremy Allison 2023-07-28 23:33:09 UTC
Can you post your smb.conf so I know what the share definition looks like please ?
Comment 2 Jeremy Allison 2023-07-29 00:17:15 UTC
OK, reproduced this on a "normal" SMB2 share.
Comment 3 Jeremy Allison 2023-07-29 00:22:54 UTC
I'm leaning to thinking that 4.18 is doing the right thing and 4.16 is incorrect here.

The object exists, even though we can't see it. A dangling symlink is similar to a vetoed file, in that it prevents operations on it.

Let me see how we behave if the target is a vetoed file.
Comment 4 Jeremy Allison 2023-07-29 00:26:15 UTC
Yep, renaming a file on top of a vetod file return the same error: NT_STATUS_OBJECT_NAME_NOT_FOUND.

I'd argue that we are at least consistent here now.

Bjorn, can you discuss with Ralph and Metze to see if they agree with me ?
Comment 5 Björn Jacke 2023-12-07 09:30:39 UTC
isn't the problem how we deal with dangling symlinks? If a dangling symlink on the server is not being listed but it causes errors and unexpected things to happen out of the blue from the client's perspective. Maybe we should not hide dangling symlinks but show it as a file with no read permissions instead? Just an idea. The current way how we handle dangling symlinks is far from ideal in any case I think.
Comment 6 Björn Baumbach 2024-01-30 19:59:40 UTC
*** Bug 15489 has been marked as a duplicate of this bug. ***