Bug 2096405

Summary:	Manual configuration in root partition required before Samba shares can be created
Product:	[Fedora] Fedora	Reporter:	Nate Graham <nate>
Component:	samba	Assignee:	Andreas Schneider <asn>
Status:	CLOSED ERRATA	QA Contact:	Denis Karpelevich <dkarpele>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	37	CC:	abokovoy, aboscatt, anoopcs, asn, dkarpele, gdeschner, iboukris, jarrpa, jstephen, lmohanty, madam, ngompa13, pfilipen, sbose, ssorce, travier
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	samba-4.17.0-1.fc38 samba-4.17.0-1.fc37	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-09-13 19:52:22 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Nate Graham 2022-06-13 18:25:44 UTC

On Fedora, if the user wants to create a Samba share, they need to do the following:

1. Install the package providing Samba server functionality

2. Add the following lines to the [global] group of /etc/samba/smb.conf:

  usershare path = /var/lib/samba/usershares
  usershare max shares = 100
  usershare allow guests = yes
  usershare owner only = yes

3. Create /var/lib/samba/usershares and set its group to something the user can become a member of without compromising security (i.e. not "root"; in Arch, openSUSE, and Ubuntu for example, they use a group called "usershares").

4. Put the user in that group and reboot or refresh the running session

5. Create the samba share using most likely some GUI method


In KDE, we have a project called kdenetwork-filesharing that guide the user through doing steps #1, #4, and #5. However it cannot do #2 because any changes it makes would be overridden by distro package updates. It could theoretically do #3 but in general we want to avoid messing with the OS partition, especially with immutable OSs becoming more common going forward.

It would be lovely if the Samba packaging could automatically set up usershares by default, such that simply installing the package providing Samba server functionality was all that's needed. It wouldn't have to be the base package if that's problematic; for our purposes, if would even work if there was a samba-enable-usershares package that did steps #2 and #3 (and ideally #4 too) when installed.

Comment 1 Nate Graham 2022-06-13 18:34:39 UTC

Relevant upstream bug report: https://bugs.kde.org/show_bug.cgi?id=425202

Comment 2 Andreas Schneider 2022-06-22 09:39:18 UTC

What we could do is to create a samba-usershares package which does the following:

a) Create /etc/samba/usershares.conf with the following config:

[global]   
  usershare path = /var/lib/samba/usershares
  usershare max shares = 100
  usershare allow guests = yes
  usershare owner only = yes

b) Add a comment out "# include /etc/samba/usershares.conf"

c) Create a group "usershares"

d) Create /var/lib/samba/usershares and give "usershares" access to it.


The user would still need to edit /etc/samba/smb.conf and add the user to the usershares group after installing the package. Would that be fine with you?

Comment 3 Nate Graham 2022-06-27 21:02:06 UTC

Allowing the user (or a piece of user software) to install a specific package to enable this functionality makes sense and works. Our software can also add the user to the sambashares group and recommend a reboot, so that's fine too. But anything that requires manually editing smb.conf won't work, I'm afraid. Any changes the user or the software makes to that file can get overwritten with the next distro upgrade. So ideally no manual changes to the default smb.conf file would be required here. Since we're making a separate distro package that enables usershares when installed, it would be best if its packaging postinstall hookscript could take care of uncommenting that "include" line when the package is installed, and commenting it back out when the package is uninstalled.

Comment 4 Ben Cotton 2022-08-09 13:17:53 UTC

This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle.
Changing version to 37.

Comment 5 Fedora Update System 2022-09-13 19:46:05 UTC

FEDORA-2022-a457400fcd has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2022-a457400fcd

Comment 6 Fedora Update System 2022-09-13 19:52:22 UTC

FEDORA-2022-a457400fcd has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 7 Fedora Update System 2022-09-14 08:01:31 UTC

FEDORA-2022-4555909843 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-4555909843

Comment 8 Fedora Update System 2022-09-15 01:48:12 UTC

FEDORA-2022-4555909843 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-4555909843`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-4555909843

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 9 Fedora Update System 2022-09-16 00:16:40 UTC

FEDORA-2022-4555909843 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.