10.5 C
London
Saturday, September 14, 2024

smb – smbd on macOS: Shares seem empty, solely directories (no recordsdata)?


I hope to make samba.org’s smbd run on my MBP (M1, 13.6.2) to supply shares to some VMs (qemu/ UTM) on and restricted to the identical host. I succeeded in putting in Samba through MacPorts and through homebrew, I created some take a look at shares (incl. a public one permitting for visitor entry), however there may be an anomaly: I can entry the shares utilizing smbclient from the macOS host, from any VM (working Home windows, working Linux), however they seem empty:

It is a macOS native listing (permissions are set as permissive):

/tmp/publictest (drwxrwxrwx: <username>:employees)
└── dummy-1.pdf (-rw-rw-rw-@: <username>:employees)

<username> refers to my macOS person title, for Samba shares and so forth. I created a sharing-only macOS-local person sambauser (505) as a member of group employees (20).

The listing is uncovered as a share (smb.conf):

[public]
    ea assist = No
    pressure create mode = 0666
    pressure listing mode = 0777
    visitor okay = Sure
    visitor solely = Sure
    path = /tmp/publictest
    learn solely = No
    retailer dos attributes = No

Working domestically, from the identical macOS machine, yields:

% /choose/homebrew/bin/smbclient //localhost/public
Password for [WORKGROUP<username>]:
Nameless login profitable
Attempt "assist" to get an inventory of attainable instructions.
smb: > ls
  .                                   D        0  Sat Nov 25 11:04:43 2023
  ..                                  D        0  Sat Nov 25 11:04:43 2023

        482797652 blocks of dimension 1024. 108446544 blocks accessible

So, dummy-1.pdf is lacking?!

Logging reveals (--debuglevel=10 --debug-stdout --foreground):

file_name_hash: /personal/tmp/publictest/. hash 0x7aedb117
push_sec_ctx(4294967294, 4294967294) : sec_ctx_stack_ndx = 1
push_conn_ctx(1627971036) : conn_ctx_stack_ndx = 0
setting sec ctx (0, 0) - sec_ctx_stack_ndx = 1
Safety token: (NULL)
UNIX token of person 0
Major group is 0 and accommodates 0 supplementary teams
pop_sec_ctx (4294967294, 4294967294) - sec_ctx_stack_ndx = 0
fd_openat: title ., flags = 04 mode = 00, fd = 26
openat_pathref_fullname: fsp [.]: OK
fdos_mode: .
dos_mode_debug_print: dos_mode_from_sbuf returning (0x10): "d"
dos_mode_debug_print: fdos_mode returning (0x10): "d"
smbd_dirptr_get_entry: masks=[*] discovered . fname=.. (..)
smbd_marshall_dir_entry: space_remaining = 8388488
smbd_marshall_dir_entry: SMB_FIND_ID_BOTH_DIRECTORY_INFO
delete_lock_ref_count for file .
file_free: freed recordsdata construction 0 (1 used)
smbd_dirptr_get_entry: dir [.] dirptr [0x131e123c0] offset [3] => dname [dummy-1.pdf]
openat_pathref_fsp_nosymlink: path_in=dummy-1.pdf
fsp_new: allotted recordsdata construction (2 used)
openat_pathref_fsp_nosymlink: SMB_VFS_OPENAT(., dummy-1.pdf, RESOLVE_NO_SYMLINKS) returned 78 Perform not carried out => NT_STATUS_NOT_SUPPORTED
readlink_talloc: SMB_VFS_READLINKAT() failed: No such file or listing
read_symlink_reparse: readlink_talloc failed: NT_STATUS_OBJECT_NAME_NOT_FOUND
openat_pathref_fsp_nosymlink: create_open_symlink_err failed: NT_STATUS_OBJECT_NAME_NOT_FOUND
file_free: freed recordsdata construction 0 (1 used)
smbd_dirptr_get_entry: Couldn't open dummy-1.pdf: NT_STATUS_NOT_A_DIRECTORY
smbd_dirptr_get_entry: dir [.] dirptr [0x131e123c0] offset [3] => dname [(finished)]
smbd_smb2_request_find_done: out_output_buffer.size = 220

That is the place I’m caught. I’ve failed to grasp (to date) why dummy-1.pdf is processed (as a listing), however not merely as a file.


  • Samba model (through Homebrew):

    sudo /choose/homebrew/sbin/samba-dot-org-smbd –version
    Model 4.19.2

  • World parameters:

    [global]
    permit insecure large hyperlinks = Sure
    bind interfaces solely = Sure
    interfaces = lo0
    max log dimension = 50
    safety = USER
    server function = standalone server
    server string = samba server
    idmap config * : backend = tdb

  • smbd (MacPorts) and samba-dot-org-smbd (homebrew) are registered for “Full Disk Entry”:

enter image description here

  • As I said earlier, this isn’t a Samba consumer situation (e.g., SELinux being energetic on some Linux VM or so). The behaviour is reproducible for any Samba consumer/ distant machine I had been testing (e.g., mounting in Powershell on Home windows 2022 server, and so forth.)

  • I checked the MacPorts and Homebrew tickets, no point out of this downside.

  • macOS-own smbd is inactive, and File Sharing is deactivated.

Latest news
Related news

LEAVE A REPLY

Please enter your comment!
Please enter your name here