Home / server / Questions / 90315
Accepted
EvanK
Asked: 2009-12-03 11:35:29 +0800 CST

Particular Windows user(s) connecting to samba share as 'nobody' instead of given username?

  • 772

We have an Ubuntu 9.04 server running samba with null passwords and home directory shares, and we have corresponding users that mount said shares on windows machines. Essentially, each user has an account on the server (with the same username as on their windows machines) and a home directory in /home/USERNAME which is mounted on their local machine as \\SAMBABOX\USERNAME which they then have full access to.

For most users this works without a problem; they can read, write, create, and delete files on their shares without issue. Following is one such initial connection as seen in the samba logs:

[2009/12/02 10:30:22,  1] smbd/service.c:make_connection_snum(1115)
  somewindowsbox (192.168.2.123) connect to service ekaufman initially as user ekaufman (uid=1002, gid=1002) (pid 22574)

For one user in particular, however, they are unable to - at the very least - create certain files (lock files for an SVN working copy). This is, mind you, from any windows machine in our AD domain. Looking at their samba logs, their initial connection is made as the user nobody, and I cannot for the life of me figure out why.

[2009/11/18 10:19:32,  1] smbd/service.c:make_connection_snum(1115)
  somewindowsbox (192.168.2.123) connect to service jdoe initially as user nobody (uid=65534, gid=65534) (pid 15570)

Their user account on the ubuntu server is more or less identical to the others, as indicated in /etc/passwd:

ekaufman:x:1002:1002:,,,:/home/ekaufman:/bin/bash
jdoe:x:1015:1015:,,,:/home/jdoe:/bin/bash

And /etc/group:

ekaufman:x:1002:
jdoe:x:1015:

And even /etc/shadow (with the password hashes removed before being posted here, of course):

ekaufman:!:14580:0:99999:7:::
jdoe:!:14572:0:99999:7:::

I've even deleted their account on the ubuntu box and recreated it, with no change. According to the admin of the AD domain controller, their account there is more or less identical to everyone elses as well (deleting and recreating it there would be prohibitively complicated).

If I manually mount the share for my own account from a windows machine, forcing the username, it works without incident:

C:\> net use z: \\sambabox.local\ekaufman /user:ekaufman
The command was completed successfully

If I do the same for this particular user, it still connects as nobody, failing silently:

C:\> net use z: \\sambabox.local\jdoe  /user:jdoe
The command was completed successfully

This gives me the impression that, whatever the problem is, it's on the linux side of things.

This is the entire smb configuration in use:

[global]
   null passwords = yes
   guest ok = yes
   security = user
   workgroup = WORKGROUP
   server string = %h server (Samba, Ubuntu)
   dns proxy = no
   log file = /var/log/samba/log.%m
   max log size = 1000
   syslog = 0
   panic action = /usr/share/samba/panic-action %d
   encrypt passwords = true
   passdb backend = tdbsam
   obey pam restrictions = yes
   unix password sync = yes
   passwd program = /usr/bin/passwd %u
   passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
   pam password change = yes
   map to guest = bad user
   usershare allow guests = yes

[homes]
   comment = Home Directories
   browseable = no
   read only = no

[printers]
   comment = All Printers
   browseable = no
   path = /var/spool/samba
   printable = yes
   guest ok = no
   read only = yes
   create mask = 0700

[print$]
   comment = Printer Drivers
   path = /var/lib/samba/printers
   browseable = yes
   read only = yes
   guest ok = no
linux

3 Answers

  1. I found the error to be user name mapping in users.map, which I had previously used to correlate NIS usernames to A.D. accounts. After switching all NIS to the A.D. ServicesForUNIX NIS, I'd forgotten to remove these old username mappings.

    • 1

  2. On my system, there is a group called "sambashare". See if jdoe is a member (along with everybody else).

    • 0
  3. Best Answer

    As it turns out, the answer was deceptively simple. In addition to the user needing an account on the linux machine, they also had to be added to the smbpasswd file. Additionally, since the connections are being made with null passwords, we need to add them with a null password to said file:

    # -a flag adds the new user (must already exist in /etc/passwd)
# -n flag indicates a null password (different from an empty password)
smbpasswd -an jdoe
    • 0