when widelinks = yes is set DFS (at least in the case of local DFS pointing at local shares fail) e.g. with following setup [global] map to guest = Bad User server role = standalone server wide links = yes unix extensions = no [guest] path = /srv/samba/guest/ read only = no guest ok = yes guest only = yes msdfs root = yes [1] create local share dir mkdir -p /srv/samba/guest [2] create msdfs link ln -snf msdfs:$(hostname -f)\\guest /srv/samba/guest/linka [3] start smbd [4] try to access dfs link smbclient --no-pass //localhost/guest -c "cd linka" will result in NT_STATUS_OBJECT_NAME_NOT_FOUND
seems this was introduced in 4.17 by d20b60c3200b5e1881cdf4b59da154d1af7e3994 but the code around this has changed since again I think basically it seems with the current code with widelinks enabled the vfs stack goes as follows openat_pathref_fsp_case_insensitive -> openat_pathref_fullname -> fd_openat -> non_widelink_open -> SMB_VFS_OPENAT -> widelinks_openat which ends up failing with NT_STATUS_OBJECT_NAME_NOT_FOUND *but* with the associated stat buf invalide (because widelinks follow the symlink which in the case of a dfs link is invalid so it resolves to a bad / non existent object in the normal case it is the link that is attempted to open (which fails for the normal reasons) *but* the associated stat buf is valid so the subsequent tests can determine it is a link, a dfs link etc. and process appropriatly
Is there a place in that call-stack where we have a valid stat for the dfs link path ? If so we might be able to do something different in the 'widelinks = yes' case.
widelinks_openat() is ugly, dirty and specific enough we might be able to do something in there to restore the old behavior :-).
(In reply to Jeremy Allison from comment #2) >Is there a place in that call-stack where we have a valid stat for the dfs link >path ? > >If so we might be able to do something different in the 'widelinks = yes' case. I didn't see one, but I could easily have missed, I opened this draft with a (as it says in the commit message) 'dodgy (tm)' attempt at fixing https://gitlab.com/samba-team/samba/-/merge_requests/3195
I.e. if the SMB_VFS_NEXT_OPENAT() call in widelinks_openat() fails with -1, errno =ENOENT, then do an SMB_VFS_NEXT_LSTAT() on the name and see if it matches a DFS name, fill in the stat field if so. This may not be the right place of course, so look in the "normal" DFS path case (when widelinks=no) and see where the returned struct stat gets filled in.
This bug was referenced in samba master: b57cdfd7efb161cf96b3a39dc7a1652db817e602 3d2e9db8b95f9f45d486f8272e53584975f177fa 2668dcd0968133cca4f8410bf8c41ed0483f5d87 0bf8b25aacdf2f5c746922320b32e3f0886c81f5
Created attachment 18013 [details] backport for 4.18 & 4.17 backport should apply to 4.17 & 4.18
Re-assigning to Jule for inclusion in 4.18.next, 4.17.next.
Pushed to autobuild-v4-{18,17}-test. Could you please also create a patch for 4.19? The 4.18/4.17 patch did not apply to 4.19.
This bug was referenced in samba v4-18-test: e50f377b4ab853b11ea17778a3e5ea712548bc22 5db858c1afde2fd0a20c81360f03f165eee2d53b e949750d4f533d0c2a04ada4a02236f1b012107a c40f1619d96c0332d3ad9d9b8e63a4fbc10f332f
(In reply to Jule Anger from comment #9) >Could you please also create a patch for 4.19? >The 4.18/4.17 patch did not apply to 4.19. so sorry, I didn't realise we had branched :-( (will backport now)
Created attachment 18022 [details] backport for 4.19 I don't think a a re(review) is needed for this patch version (only context diffs here) but please let me know if it is needed
Thanks :-) Pushed to autobuild-v4-19-test.
This bug was referenced in samba v4-17-test: 9ace53099ed5cc9cb3cabe2f104882b0f260ea43 98a53e95a0f36e60355e3e2d2719018cd485f436 b63c917cf742682f909597349d2f1f513c422ec7 10f3fafc6f4fedbc182894c3d03fd2939cfcee18
This bug was referenced in samba v4-19-test: d59392056e796c2c491e5f53dac2f9161b329bf4 ece48278912e14432f34f6d0edcd26768e299406 368b3e6102b5a7d9df0f243ced7d75fe8605eb79 1231268c219a2f00ad62c7d109db96129b0d2388
Closing out bug report. Thanks!
This bug was referenced in samba v4-19-stable (Release samba-4.19.0rc2): d59392056e796c2c491e5f53dac2f9161b329bf4 ece48278912e14432f34f6d0edcd26768e299406 368b3e6102b5a7d9df0f243ced7d75fe8605eb79 1231268c219a2f00ad62c7d109db96129b0d2388
This bug was referenced in samba v4-18-stable (Release samba-4.18.6): e50f377b4ab853b11ea17778a3e5ea712548bc22 5db858c1afde2fd0a20c81360f03f165eee2d53b e949750d4f533d0c2a04ada4a02236f1b012107a c40f1619d96c0332d3ad9d9b8e63a4fbc10f332f
This bug was referenced in samba v4-17-stable (Release samba-4.17.11): 9ace53099ed5cc9cb3cabe2f104882b0f260ea43 98a53e95a0f36e60355e3e2d2719018cd485f436 b63c917cf742682f909597349d2f1f513c422ec7 10f3fafc6f4fedbc182894c3d03fd2939cfcee18
According to my testing (samba 4.19.6) the DFSROOT option still does not work if "wide links" is enabled. If wide links is disabled and nothing else changed, the DFS root works again.
(In reply to Michael Thalmann from comment #20) Works for me laptop:/home/npower/samba-clone # cat INSTALL_DIR/etc/smb.conf [global] map to guest = Bad User server role = standalone server wide links = yes unix extensions = no [guest] path = /srv/samba/guest/ read only = no guest ok = yes guest only = yes msdfs root = yes laptop:/home/npower/samba-clone # ./bin/smbd --version Version 4.19.6 laptop:/home/npower/samba-clone # ps -efl | grep smbd 5 S root 1426 29973 0 80 0 - 24493 do_epo 20:16 pts/4 00:00:00 ./bin/smbd --no-process-group 5 S root 1432 1426 0 80 0 - 23856 do_epo 20:16 pts/4 00:00:00 smbd: notifyd 5 S root 1433 1426 0 80 0 - 23858 do_epo 20:16 pts/4 00:00:00 smbd: cleanupd 0 S root 1510 4888 0 80 0 - 1411 pipe_r 20:17 pts/4 00:00:00 grep --color=auto smbd laptop:/home/npower/samba-clone # laptop:/home/npower/samba-clone # ./bin/smbclient --no-pass //localhost/guest -c "cd linka;dir" . D 0 Sat Jun 1 20:03:41 2024 .. D 0 Sat Jun 1 20:03:41 2024 foo N 0 Sat Jun 1 20:03:38 2024 bar N 0 Sat Jun 1 20:03:41 2024 148707328 blocks of size 1024. 114921392 blocks available laptop:/home/npower/samba-clone # ls -lrt /srv/samba/guest total 4 lrwxrwxrwx 1 root root 23 Jun 1 20:02 linka -> msdfs:192.168.1.6\guest -rw-r--r-- 1 root root 0 Jun 1 20:03 foo -rw-r--r-- 1 root root 0 Jun 1 20:03 bar can you give more details or better still simplest reproducer, it's possible you are triggering a new bug
I had working dfs yesterday (and for over a decade) however Rocky 8.10 had an update to samba-4.19.4 and dfs has stopped working. I am unsure of the previous version. I do believe I have wide links enabled.
Turning off wide links seems to have fixed the issue: #wide links = yes wide links=no now I see the dfs on the windows machines.
Turning off wide links seems to have fixed the issue: #wide links = yes wide links=no now I see the dfs on the windows machines. Looks like the update was from 4.18.6 to 4.19.4: Upgrade samba-4.19.4-3.el8.x86_64 @baseos Upgraded samba-4.18.6-3.el8_9.x86_64 @@System Upgrade samba-client-libs-4.19.4-3.el8.x86_64 @baseos Upgraded samba-client-libs-4.18.6-3.el8_9.x86_64 @@System Upgrade samba-common-4.19.4-3.el8.noarch @baseos Upgraded samba-common-4.18.6-3.el8_9.noarch @@System Upgrade samba-common-libs-4.19.4-3.el8.x86_64 @baseos Upgraded samba-common-libs-4.18.6-3.el8_9.x86_64 @@System Upgrade samba-common-tools-4.19.4-3.el8.x86_64 @baseos Upgraded samba-common-tools-4.18.6-3.el8_9.x86_64 @@System Upgrade samba-dcerpc-4.19.4-3.el8.x86_64 @baseos Upgraded samba-dcerpc-4.18.6-3.el8_9.x86_64 @@System Upgrade samba-ldb-ldap-modules-4.19.4-3.el8.x86_64 @baseos Upgraded samba-ldb-ldap-modules-4.18.6-3.el8_9.x86_64 @@System Upgrade samba-libs-4.19.4-3.el8.x86_64 @baseos Upgraded samba-libs-4.18.6-3.el8_9.x86_64 @@System Upgrade samba-winbind-4.19.4-3.el8.x86_64 @baseos Upgraded samba-winbind-4.18.6-3.el8_9.x86_64 @@System Upgrade samba-winbind-clients-4.19.4-3.el8.x86_64 @baseos Upgraded samba-winbind-clients-4.18.6-3.el8_9.x86_64 @@System Upgrade samba-winbind-modules-4.19.4-3.el8.x86_64 @baseos Upgraded samba-winbind-modules-4.18.6-3.el8_9.x86_64 @@System
Is this with a source build from 4.19.x from git.samba.org ? Or is this with a vendor package (Rocky8 was mentioned). If you can reproduce with a source build from git.samba.org I'll investigte, otherwise it may be a problem with the vendor package.
(In reply to Jeremy Allison from comment #25) so looking again (it appears I am blind) in my test (against upstream 4.19.6) # ./bin/smbclient --no-pass //localhost/guest -c "cd linka;dir" . D 0 Sat Jun 1 20:03:41 2024 .. D 0 Sat Jun 1 20:03:41 2024 foo N 0 Sat Jun 1 20:03:38 2024 bar N 0 Sat Jun 1 20:03:41 2024 fine? erm no.. we are missing the entry for the dfs linka entry this isn't missing when widelinks = no (default) we would get the same result if we did ./bin/smbclient --no-pass //localhost/guest -c "dir" . D 0 Sat Jun 1 20:03:41 2024 .. D 0 Sat Jun 1 20:03:41 2024 foo N 0 Sat Jun 1 20:03:38 2024 bar N 0 Sat Jun 1 20:03:41 2024 BUT... we can cd linka (even though it isn't enumerated) so there is a problem. Note this doesn't happen on master but on master (and most likely on 4.19 aswell) the first 'cd' will work but the second will not e.g. ./bin/smbclient --no-pass //localhost/guest smb: \> dir . D 0 Fri Jun 7 20:48:27 2024 .. D 0 Fri Jun 7 20:48:27 2024 linka Dr 0 Mon Jul 24 21:49:46 2023 foo N 0 Fri Jun 7 20:48:27 2024 bar N 0 Fri Jun 7 20:48:27 2024 220098560 blocks of size 1024. 50010836 blocks available smb: \> cd linka smb: \linka\> dir . D 0 Fri Jun 7 20:48:27 2024 .. D 0 Fri Jun 7 20:48:27 2024 linka Dr 0 Mon Jul 24 21:49:46 2023 foo N 0 Fri Jun 7 20:48:27 2024 bar N 0 Fri Jun 7 20:48:27 2024 220098560 blocks of size 1024. 50010836 blocks available smb: \linka\> cd linka cd \linka\linka\: NT_STATUS_OBJECT_PATH_NOT_FOUND smb: \linka\> In short I think (although related) these are different but separate problems (might be worth keeping them under the same bug, I dunno what is more effective or confusing) The 'missing' dir entry in 4.19 is can be fixed by tweaking openat_pathref_fsp_nosymlink to return NT_STATUS_STOPPED_ON_SYMLINK when it encounters a dfs link (I have a hacky patch for this) which also seems to fix the entering into nested dfs link dir. fixing the nested dfs entry on master might be a bit more problematic, the code has changed around this a bit I think and maybe posix stuff intersects too
Created attachment 18331 [details] start of extra patch for 4.19 This no doubt isn't correct, I spent enough time today poking around some of this code to realise I am not smart enough to understand the subtleties here. But it should at least give some ideas
Created attachment 18332 [details] start of extra patch for master if the previous 4.19 patch is in the right direction then this might be a follow-up (but like I said, I really feel dumb about this stuff)
Noel, can you retest this with the patch being tested in: https://gitlab.com/samba-team/devel/samba/-/pipelines/1326402431 please ? This is certainly in a related area.
This bug was referenced in samba master: 7f1de90f72d6e8287aec6ab1d9f7776b7df624e5 788ef8f07c75d5e6eca5b8f18d93d96f31574267
Created attachment 18335 [details] patch for 4.20 backport for 4.20 - minor change here due to different methods for reading symlink NOTE: This patch should be applied *after* backport for bug #15662 (or there will be an unexpected failure in the tests)
Created attachment 18336 [details] backported patch for 4.19 backport for 4.19, a couple of more differences from master/4.20 backport. Differences are annotated at bottom of commits messages but in summary a) knowfails are adjusted, test_ci_chdir doen't fail in 4.19 but test_enumerate_dfs_link does b) In 4.19 vfs_widelink widelink_openat sets errno to ENOENT instead of ELOOP
Created attachment 18337 [details] backport for 4.18 backport for 4.18 (not sure if we are supporting that) but if not I think from a distro pov I will add it here And there are some more changes again from 4.19 backport, again these are annotated at the end of the commit message in summary a) changes to knownfails for test, only test_nested_chdir fails in this release b) modify existing code (that was already catering for ELOOP) to include ENOENT
I will try to test the patch / fixes in the next 2 weeks. I am busy on a project now but should have time soon.
Comment on attachment 18337 [details] backport for 4.18 Not sure we need this one though.
Jule can you please add the 4.20.next and 4.19.next patches for the next releases please ! Thanks, Jeremy.
Pushed to autobuild-v4-{20,19}-test.
This bug was referenced in samba v4-20-test: 4b4b0152fd7cce2923ffcfe04eb07de4cc8721d7 5b90acbef156174ea65014a298f926218a760c4e
This bug was referenced in samba v4-20-stable (Release samba-4.20.2): 4b4b0152fd7cce2923ffcfe04eb07de4cc8721d7 5b90acbef156174ea65014a298f926218a760c4e
This bug was referenced in samba v4-19-test: 6c86b5199366ab3b6b3e2f38937e0a79a34c2d84 dfa0b1adb872f9c34b6fb1f4f84a06f5dd6802bc
This bug was referenced in samba v4-19-stable (Release samba-4.19.8): 6c86b5199366ab3b6b3e2f38937e0a79a34c2d84 dfa0b1adb872f9c34b6fb1f4f84a06f5dd6802bc