Bug 15925 - smbclient traverses excluded directories in tar mode
Summary: smbclient traverses excluded directories in tar mode
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Tools (show other bugs)
Version: 4.22.4
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-09-29 02:55 UTC by main.haarp
Modified: 2026-02-18 09:34 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description main.haarp 2025-09-29 02:55:52 UTC
Hello,

when tar mode is used in smbclient Version 4.22.4-Debian-4.22.4+dfsg-1~deb13u1, excludes work, i.e. they do not end up in the tar archive. However, smbclient still tries to traverse the excluded directories on the remote end.

On a Windows remote, this leads to errors such as

NT_STATUS_ACCESS_DENIED listing \Default User\*
...
...
tar:716  do_list fail NT_STATUS_ACCESS_DENIED

which then result in smbclient exiting with exit status >0, indicating failure. This breaks applications such as BackupPC that rely on the exit status. There is currently no way to properly exclude these directories from being traversed. Using a small wrapper script around smbclient that exits 0 does work tho.

I can observe the same behavior as far back as Version 4.18.9, possibly earlier. There's also #8922, which was fixed long ago. Are we dealing with a new regression? I can't exclude (heh) the possibility that I'm doing something completely wrong.


Test case:

smbclient '\\windoze\Users' -U user --password="$pw" -E -d 2 -c 'tarmode full' -mSMB3 -TcX - '//Default User' >/dev/null

Result:

NT_STATUS_ACCESS_DENIED listing \Default User\*
...
tar:716  do_list fail NT_STATUS_ACCESS_DENIED


Thank you very much!
Comment 1 Laurent Pointal 2026-02-18 09:34:20 UTC
I confirm this problem, same symptom.
Large parts of our server data are backuped, but the process finish with this error and dont complete the backup (physically and logically for BackupPC).

I used a workaround to backup this server, reusing a trick¹ we use to backup some Linux computers via NFS + local rsync in place of remote rsync (in our case it is relaly more efficient):

* Enable automounting
* Automount the CIFS volume in some path
* Do a local rsync backup of the mounted volume (see the trick)

Maybe it could be more efficient using smbclient, but tarmode trying to enter forbidden directories make it fail.

A+
L.Pointal

¹ See the trick here https://sourceforge.net/p/backuppc/mailman/backuppc-users/thread/80b12092-1b9a-2a9e-6348-d448042a230d@firewall-services.com/

Resume:
* declare the target host as localhost (in /etc/hosts: 127.0.2.1 targethost)
* automount the target volume (/etc/auto.master + /etc/auto.targethost) in a path (ex. /targethost/volume) - test it
* in /etc/sudoers: backuppc ALL=(ALL:ALL) NOPASSWD:ALL
* in BackupPC
- select rsync Xfer method
- RsyncShareName → /targethost/volume
- RsyncClientPath → /usr/bin/rsync
- RsyncSshArgs → -e
                 /usr/bin/sudo -p