How to make Samba share to NOT ASK FOR PASSWORD

Question

NOTE: I have read probably up to 50 different pages describing how to setup public Samba share in the span of 2 YEARS and nothing ever worked for me. I don't know how much RTFM I need to set this stuff.

I need/want to setup a completely open public file share on my home server for two workstations.

Setup is as follows:

Server:

• Debian Wheezy
• sudo smbd --version gives me Version 3.6.6.
• 2 local partitions which I want to share, formatted in NTFS due to being old and taken from Windows machine. I cannot format them to ext* FS because they have a lot of data I cannot (yet) move anywhere else.
• machine named "homeserv" for lack of originality.

Client:

1. Debian Testing (Jessie)
2. Windows 7 (2 different machines). In fact, my machine is Debian/Windows dualboot, and my wife's machine is Windows only.

My smb.conf after distillation looks as follows (verbatim, nothing else is there):

[global]
  workgroup = WORKGROUP
  security = user
  map to guest = Bad User

[disk1]
  comment = Disk 1 on 400GB HDD
  path = /media/disk1
  browsable = yes
  guest ok = yes
  read only = no
  create mask = 0755

[disk2]
  comment = Disk 2 on 400GB HDD
  path = /media/disk2
  browsable = yes
  guest ok = yes
  read only = no
  create mask = 0755

On both client machines, in both Debian and Windows I get the same result: login/password dialog. NO COMBINATION of security = user, map to guest = Bad user, security = share, guest ok = yes and such helped.

Windows 7 shows login/password dialog right after I click on the shared machine in network neighborhood. smb://homeserv/ file path in Debian (in any file browser) shows me two folders: disk1 and disk2, as intended, by trying to open them bring the login/password dialog.

So, what I lack in the scheme to NOT HAVE to enter login/password? This is usability question, I will not create a user-based authentication for file junkyard.

Answer 1

OK, I have found an answer myself.

As this is absolutely not obvious from the docs and HOWTOs and whatever, the reason this thing asks for password is because it cannot map guest user to the owner of the directory being shared.

I have NTFS partitions which I need to mount RW so I used the following setup in my /etc/fstab:

/dev/sdb1  /media/disk1  ntfs defaults,noexec,noatime,relatime,utf8,uid=1000,gid=1000 0       2
/dev/sdb2  /media/disk2  ntfs defaults,noexec,noatime,relatime,utf8,uid=1000,gid=1000 0       2

The most important pieces of config are uid and gid (maybe only uid, don't know). They are set to the UID and GID of the user jonnie set up on the server (obviously not root). So, when ntfs-3g will mount these disks, everything will be owned by him.

After that, I have added this user to the Samba registry (or maybe created new identical one, don't care):

# smbpasswd -a jonnie

It asked for password, I have entered the same as for the main system.

After that, I have added the force user and force group settings to the smb.conf:

[global]
  workgroup = WORKGROUP
  netbios name = HOMESERV
  security = share

[disk1]
  comment = Disk 1 on 400GB HDD
  path = /media/disk1
  browsable = yes
  guest ok = yes
  read only = no
  create mask = 666
  directory mask = 777
  force user = jonnie
  force group = jonnie

[disk2]
  comment = Disk 2 on 400GB HDD
  path = /media/disk2
  browsable = yes
  guest ok = yes
  read only = no
  create mask = 666
  directory mask = 777
  force user = jonnie
  force group = jonnie

So, most important piece of config relevant to me was force user.

Courtesy of the Samba HOWTO

Answer 2

The config can be shorter:

Create unix user jonnie

useradd jonnie -s /usr/sbin/nologin

Create smbuser

smbpasswd -a jonnie

Create the Linux directory to share

mkdir /mysmbshare

Change the owner of the directory to jonnie

chown /mysmbshare jonnie

smb.conf

[global]
  workgroup = MyWorkGroup
  server string = Hello, use me
  security = share
  guest account = jonnie
  passdb backend = tdbsam

[the_public_share]
   path = /mysmbshare
   writable = yes
   printable = no
   public = yes

All files are owned by jonnie and everyone has rw access to the files.

Answer 3

The accepted answer by "hijarian" at the time of writing is not ideal for the main reason that if the share is writable, then you cannot know which user wrote to the share. If it is a guest mount, then who cares about security and you can stop reading this now. If you care about security, read on...

By default, Windows passes the username and password of the currently logged-in user. This means that the password set with smbpasswd should match that of the user's password on the Windows client. The password may not be the empty string (at least I have not found a way to force this while also passing the authentication step).

File shares are often group-oriented (group of users need access to the same data). This is why I prefer to implement shares by groups (not by users like in most documentation):

[Musik]
writeable = true 
path = "/mnt/remote/smb/5TB/Media/Music"
valid users = @smbmedia
create mode = 2774 
directory mode = 2775 

Note the @smbmedia. This means that anyone in the group smbmedia may access this share. I have create mode and directory mode in there, but its mostly for good measure and redundant.

Because this share is writable, the default umask will apply. I like to override this because I want ensure that new files are owned by the group smbmedia and the user should be set to the user who created the file (for record keeping).

Set the sticky bit to ensure new directories keep the same ACLs (which we'll set next. CAVEAT: Without create mode and directory mode, and relying on only ACLs, note that ACLs cannot set the group sticky bit. The group stick bit will therefore only work for new directories at 1 level below the base level of the share. This means that newly created directories at level 1 will have the ACLs applied minus the group sticky bit, so that level 2 directories will assume the primary group permissions of the user that created the new directory, and not necessarily the "shared" group permissions (something like this). There are two ways to deal with this: One way it to use something like inotify to watch for new directories and apply the group sticky bit on newly created directories recursively. The other way is to push the responsibility to your samba daemon by using something like directory mode = 2775 to force the group sticky bit on all newly created directories.

SHARE_PATH="/mnt/remote/smb/5TB/Media"
chmod g+s "${SHARE_PATH}"

Set the default ACLs for new files to ensure the group remains constant

setfacl -d -m 'g:smbmedia:rwx' "${SHARE_PATH}"

Now you can be sure that new files will be created with the correct permissions so that they can be seen and changed by smb client users. This will allow anyone in the smbmedia group to change files owned by other people, however. You can adjust the ACLs accordingly.

List of other things to do:

• disable netbios (old crap)
• disable wins (old crap)
• start wsdd server https://github.com/christgau/wsdd

Answer 4

The quick and dirty way to have an open Samba share is to have:

# ----------------------- Standalone Server Options ------------------------
#
# Scurity can be set to user, share(deprecated) or server(deprecated)
#
# Backend to store user information in. New installations should
# use either tdbsam or ldapsam. smbpasswd is available for backwards
# compatibility. tdbsam requires no further configuration.

        security = share
        passdb backend = tdbsam

and have shares defines as such:

[export]
   comment = Data Export Directory
   path = /data/export
   read only = no
   public = yes
   browseable = yes
   writeable = yes
   create mask = 666
   directory mask = 777

Restart the daemon.

For Windows 7 clients, as of 2014, I've needed to set the domain policy: digitally sign communications from always to DISABLE.