50

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.

Improve this question

5 Answers 5

Reset to default
36

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 = 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 = 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

Improve this answer
5
  • 2
    "obviously not root". That's actually not so obvious. Samba has dozens of failure modes. Most result in an identical error messages. That's why you spent so much time in fruitless Google searches. Not only will a single search bring up a mixture of problems, but the answers found will also suffer from the same confusion. Using root eliminates the Linux side of security, but also allows you to diagnose the problem. If it works as root, you have a security issue at Linux level, If Samba still fails, the issue is within Samba's idea of users (they're different, and should have had unique errors) Commented Mar 14, 2017 at 18:32
  • 1
    As of 2020, this approach did not seem to work for me, but logging once as "guest" user with a made up password and telling the file manager to save it helped me solve this issue, as per askubuntu.com/questions/1116497/… Commented Jan 3, 2021 at 11:52
  • 1
    "So, most important piece of config relevant to me was force user." That did it! Thank you! +1 Commented Jul 14, 2022 at 17:53
  • Thank you, it worked. BTW, I gave empty password to sudo smbpasswd -a [user], it worked too. Commented Nov 24, 2023 at 20:16
  • Forcing user and group seems to have helped. The client was Windows 11. Commented Mar 19 at 15:07
6

The config can be shorter:

Create unix user jonnie

sudo useradd jonnie -s /usr/sbin/nologin

Create smbuser

sudo smbpasswd -a jonnie

Create the Linux directory to share

mkdir /mysmbshare

Change the owner of the directory to jonnie

sudo chown jonnie /mysmbshare

smb.conf

[global] workgroup = MyWorkGroup server string = Hello, use me security = user map to guest = Bad User 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.

Improve this answer
1
  • Yep, "change the owner of the directory to jonnie" is probably the most important part here. Thank you for much shorter solution! Commented Sep 13, 2019 at 2:49
4

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:

Improve this answer
1
  • This is a lot more robust solution from a person who evidently understands Samba's and Windows security a lot better than me. Thank you very much for this answer. Indeed, for myself, such a level of control over who wrote what was not necessary. The problem I've been solving was to get access to the shared resource at all. :D Commented May 7, 2024 at 16:10
2

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.

Improve this answer
2
  • My God, changing domain policy for supposedly public shares... (facepalm). Okay, thank you anyway, but no, I tried this just now and accessing smb://homeserv/disk1 still requires a password in Debian. I used Dolphin and Krusader file browsers. Maybe it's something in KDE though. Commented Sep 23, 2014 at 18:37
  • hey that worked! :D public = yes and 777 permissions did the trick (Win 10 hosting Ubuntu 18.04). Fortunately it is on my personal workstation so I don't have to worry about it Commented Jul 24, 2018 at 2:33
0

This one works for me. I'm sure you can take most of it out. It took me a lot of messing around to get it to work. file permissions on the directory need to be liberal as well of course 777 etc. and then trim it back a bit if you want more security. I'm sure some of these settings could probably be removed and it would still work. I've used it on Linux Mint 20 and 21, Linux Lite 6 and Kali Linux (All are Ubuntu based). It always works great for me and when connecting from a Windows 10 machine it doesn't prompt to authenticate.

I also usually install WSDD on my Linux machines so Windows can find them more easily. https://github.com/christgau/wsdd You can usually get it via APT.

sudo apt install wsdd

Cheers!

usershare owner only = false workgroup = WORKGROUP server string = %h server (Samba, Ubuntu) log file = /var/log/samba/log.%m max log size = 1000 logging = file panic action = /usr/share/samba/panic-action %d server role = standalone server 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 [Your Share Name] comment = Whatever you want it to say path = /PathToSharedDirectory browsable = yes guest ok = yes read only = no create mask = 0777
Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.