Bug 10919 - inetd mode broken when logs are inaccessible (Samba 4.0/4.1/4.2rc1)
Summary: inetd mode broken when logs are inaccessible (Samba 4.0/4.1/4.2rc1)
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Other (show other bugs)
Version: 4.2.0rc1
Hardware: x64 Linux
: P5 normal (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: Samba QA Contact
Depends on:
Reported: 2014-11-04 22:45 UTC by Peter Wu
Modified: 2014-11-05 11:11 UTC (History)
1 user (show)

See Also:

smb.conf for reproduction with socat (461 bytes, text/plain)
2014-11-04 22:45 UTC, Peter Wu
no flags Details
log.smbd (qemu, as root) (1.24 MB, text/plain)
2014-11-04 22:51 UTC, Peter Wu
no flags Details
log.smbd (bad, running as non-root, peter(1000)) (685.58 KB, text/plain)
2014-11-04 22:52 UTC, Peter Wu
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Wu 2014-11-04 22:45:20 UTC
Created attachment 10402 [details]
smb.conf for reproduction with socat

It appears that the inetd mode of smbd (for non-root users) has been broken since Samba 4 (?). This affects folder sharing in QEMU (-net user,smb=/some/path).

Steps to reproduce:

 1. Start server in inetd mode as non-root user (use attached config):
    socat TCP-LISTEN:1337,reuseaddr EXEC:"smbd -s smb.conf",nofork
 2. Run client:
    smbclient -NL -p1337

Expected results:
smbclient should return immediately, printing the "qemu" disk share.

Actual results:
smbd hangs which results in a timeout.

Earliest affected version: samba-4.0.0alpha17
Current git which is also affected: samba-4.2.0rc1-419-g6faef4d

Related links:
Comment 1 Peter Wu 2014-11-04 22:51:20 UTC
Created attachment 10403 [details]
log.smbd (qemu, as root)

This log is created with QEMU 2.1.2 and Samba 4.1.12. Surely there is a way to create this issue without QEMU, but this is my use case.

The QEMU disk image was specially prepared just for testing this Samba issue and prints the result of smbclient to serial.

QEMU was invoked with:
qemu-system-x86_64 -enable-kvm -m 4G -drive if=virtio,file=/tmp/arch.qcow2,id=vd0,snapshot=on -net user -net nic,model=virtio -serial none -vnc :0

The nested QEMU actually starts smbd:
qemu-system-x86_64 -m 1G -drive if=virtio,file=/dev/vda,id=vd0,snapshot=on -serial stdio -net nic,model=virtio -net user,smb=/usr -vnc :0
Comment 2 Peter Wu 2014-11-04 22:52:44 UTC
Created attachment 10404 [details]
log.smbd (bad, running as non-root, peter(1000))

By the way, both times, the smb.conf file was modified to add a single 'log level=10' line to the global config. This is the config which was generated by QEMU 2.1.2:

log level=10
private dir=/tmp/qemu-smb.20473-0
socket address=
pid directory=/tmp/qemu-smb.20473-0
lock directory=/tmp/qemu-smb.20473-0
state directory=/tmp/qemu-smb.20473-0
ncalrpc dir=/tmp/qemu-smb.20473-0/ncalrpc
log file=/tmp/qemu-smb.20473-0/log.smbd
smb passwd file=/tmp/qemu-smb.20473-0/smbpasswd
security = user
map to guest = Bad User
read only=no
guest ok=yes
force user=peter
Comment 3 Peter Wu 2014-11-05 09:27:29 UTC
Looking in the pcap capture, I see an error about an unwritable log file. This is fixed by invoking smbd with the -l option:

    smbd -s smb.conf -l /tmp/smbs/

If log messages were written to stderr rather than stderr, then this problem would not have occurred.