Sharing folder in Files: "net usershare" returned error 255

Bug #1915674 reported by 8765pu
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
samba (Ubuntu)
Expired
Wishlist
Unassigned

Bug Description

I'm just guessing package name since I can't simply read my way to that information in the GUI...

I'm trying to share my games folder on the network by right clicking and selecting the Share on local network option.

I tick Share this folder, and confirm. I expected the folder to be shared, but instead I get the message:

"net usershare" returned error 255: net usershare add: share name games is already a valid system user name

Ubuntu 20.10

ProblemType: Bug
DistroRelease: Ubuntu 20.10
Package: nautilus 1:3.38.1-1ubuntu1
ProcVersionSignature: Ubuntu 5.8.0-43.49-generic 5.8.18
Uname: Linux 5.8.0-43-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 2.20.11-0ubuntu50.5
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Mon Feb 15 02:05:28 2021
InstallationDate: Installed on 2020-10-30 (107 days ago)
InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Release amd64 (20201022)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=sv_SE.UTF-8
 SHELL=/bin/bash
SourcePackage: nautilus
UpgradeStatus: No upgrade log present (probably fresh install)
usr_lib_nautilus:
 evince 3.38.0-1
 file-roller 3.38.0-1
 nautilus-extension-gnome-terminal 3.38.0-1ubuntu1.1
 nautilus-share 0.7.3-2ubuntu3

Revision history for this message
8765pu (8765pukxbhc876y-deactivatedaccount) wrote :
affects: nautilus (Ubuntu) → nautilus-share (Ubuntu)
Changed in nautilus-share (Ubuntu):
importance: Undecided → Low
Revision history for this message
Chow Loong Jin (hyperair) wrote : Re: [Bug 1915674] [NEW] Sharing folder in Files: "net usershare" returned error 255

On Mon, Feb 15, 2021 at 04:21:02PM -0000, Launchpad Bug Tracker wrote:
> You have been subscribed to a public bug:
>
> I'm just guessing package name since I can't simply read my way to that
> information in the GUI...
>
> I'm trying to share my games folder on the network by right clicking and
> selecting the Share on local network option.
>
> I tick Share this folder, and confirm. I expected the folder to be
> shared, but instead I get the message:
>
> "net usershare" returned error 255: net usershare add: share name games
> is already a valid system user name

Well it sounds like you can't have a share with the same name as a
username, and there's a `games` user in Ubuntu by default. Pick another
share name perhaps?

--
Kind regards,
Loong Jin

Revision history for this message
8765pu (8765pukxbhc876y-deactivatedaccount) wrote :

Thanks for the suggestion for a workaround.

If true, sounds like an unreasonable limitation and implementation detail worthy of someone's attention, considering it is entirely reasonable to create a share called "games".

Revision history for this message
Chow Loong Jin (hyperair) wrote :

Reassigning this to samba, this can't be fixed in nautilus-share

affects: nautilus-share (Ubuntu) → samba (Ubuntu)
Revision history for this message
Chow Loong Jin (hyperair) wrote :

I see that the feature that it seems to conflict with is the `[homes]` section in /etc/samba/smb.conf (which makes it so that every user's home directory is exported as a share), so maybe commenting out that whole section and restarting samba might do the trick.

See https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html for more information about this.

Revision history for this message
8765pu (8765pukxbhc876y-deactivatedaccount) wrote :

I'm having trouble to determine whether messages are directed at me or are general discussion of potential fixes. If at me then thank you for the workaround, although I'm sure the first one will work. Don't worry about me. If not, it sounds like you've found the problem. It's not really expected or desirable to have arbitrary built-in users automatically reserve common words in order that they might someday share their arbitrary files that real users don't care about.

Im starting to suspect I can't create shares called "audio" or "video" either, although I haven't tried...

Revision history for this message
Sergio Durigan Junior (sergiodj) wrote :

Thanks for bug report.

I attempted to reproduce it here, but could not. Here's what I did (inside a LXD Groovy container):

# id games
uid=5(games) gid=60(games) groups=60(games)
# apt install -y libglib2.0-bin gvfs gvfs-backends dbus-x11 samba
# eval $(dbus-launch --sh-syntax)
# cat /etc/samba/smb.conf
...
[games]
   path = /testshare
   browseable = yes
   read only = yes
   guest ok = yes
# gio mount -a smb://127.0.0.1/games
# echo $?
0
# gio info smb://127.0.0.1/games
display name: games on 127.0.0.1
edit name: /
name: /
type: directory
size: 0
uri: smb://127.0.0.1/games/
local path: /run/user/0/gvfs/smb-share:server=127.0.0.1,share=games
...

The default smb.conf that is shipped in Groovy doesn't come with the "[homes]" share enabled, but even after enabling it I'm still able to set up the "games" share and mount it.

Could you please provide your smb.conf?

Revision history for this message
8765pu (8765pukxbhc876y-deactivatedaccount) wrote :

/etc/samba/smb.conf is attached. I have not touched it since system install afaik.

This is the first time I try to share anything on the system. The only existing share I can see in Files is "$print" so I have no immedately tangible clue as to why it should refuse.

I also tried sharing with the reasonable share name "Backup", since that word is also an existing user name on the system, and it refused that as well.

(Although tangential to the issue, I can confirm that using other share names succeed.)

Revision history for this message
Paride Legovini (paride) wrote :

The [homes] section is commented out in the provided smb.conf. I could reproduce it locally by running:

  $ net usershare add games /tmp/X
  net usershare add: share name games is already a valid system user name

again with [homes] commented out (the default). This seems to be a known limitation, I found questions more than 10 years old on the same problem, interestingly often hit because of the 'games' user. This limit is something samba implements, it's not Ubuntu-specific and doesn't appear to be configurable:

https://github.com/samba-team/samba/blob/8b4c6fb7c84e12498a799d155ef6dd439c3fc222/source3/utils/net_usershare.c#L734

I think this is a Wontfix, but I'm marking it as Incomplete for the moment, let's see if we all agree.

Changed in samba (Ubuntu):
status: New → Incomplete
importance: Low → Wishlist
Revision history for this message
8765pu (8765pukxbhc876y-deactivatedaccount) wrote :

Well, I don't know much about how bug statuses are used. As I see it you don't need more info from me so I'm going to assume that the status definitions aren't accurate here.

What does "incomplete" mean? And "won't fix"?

Does "won't fix" include:

- Not putting any pressure on samba to make things configurable?
- Not considering a more configurable alternative?
- Not considering using user accounts more conservatively for things they were presumably not intended (at least according to samba), or at least with non-common names?

It appears Samba does not agree with the the purpose to which you've put user accounts, or they would've made this easily configurable. As it is now, according to the info in this thread, samba's view seems to be that every single user account is relevant for file sharing, I.e. every single user account is backed by a real person. Sounds a bit optimistic.

Revision history for this message
Paride Legovini (paride) wrote :

Hi,

By proposing to set the status to Wontfix I recognize that not being able to setup usershares named like users can be an annoyance, at least in some cases, but realistically we're not going to put any effort towards fixing it. We certainly won't deviate from samba upstream: the regression potential and maintenance burden would not be justified by the importance of this bug. The Invalid state would also work here, as this is technically "not a bug in Ubuntu" as samba is behaving as expected. The boundary is sometimes a bit blurry. My effort here is not to set wrong expectations.

Anyway I think you *can* setup a share named "games" by setting it up in smb.conf (look at what Sergio did in comment #7). IIUC it's just `net usershare add` that is prevented from setting up shares named like users, and personally I find this limitation reasonable, as there are also security implications. If you really think Samba should be more flexible here my suggestion is to bring up the issue with the upstream Samba project.

Revision history for this message
8765pu (8765pukxbhc876y-deactivatedaccount) wrote :

Hello,

Thank you for your reply.

Thanks for clarifying. Just trying to follow along in the reasoning and gauge what kind of bug reports have any effect and are worth reporting in the future.

You are right, samba seems to have been installed by me and is technically not part of Ubuntu. Managing expectations is wise. The only expectation that I feel justified having when reporting bugs is that the report is considered and the decision backed by reasoning, which it is.

Technically, is the GUI that facilitates easy sharing a part of Files and therefore Ubuntu? In light of your understanding that this operation is in fact possible, it seems that that the GUI is the faulty component.

I view samba and its tools as an implementation detail of the sharing dialog in Files, which is why I have the expectation that the dialog is there to isolate me from samba intricacies, even if it means displaying another dialog asking for confirmation before performing the operation that samba judges to be a mistake.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

> Technically, is the GUI that facilitates easy sharing a part of Files and therefore Ubuntu? In
> light of your understanding that this operation is in fact possible, it seems that that the GUI
> is the faulty component.
>
> I view samba and its tools as an implementation detail of the sharing dialog in Files, which is
> why I have the expectation that the dialog is there to isolate me from samba intricacies, even
> if it means displaying another dialog asking for confirmation before performing the operation
> that samba judges to be a mistake.

I was thinking about assigning this to the desktop-team (as I'd not know which component does the UI for this), but then I realized this would IMHO have no gain.

The current error tells the user "share name games is already a valid system user name".
If one would now extend the GUI to better "isolate me from samba intricacies" and as your example describes maybe by "another dialog asking for confirmation before performing the operation that samba judges to be a mistake".
It would then tell the user "I'm not going to send this request to samba as it will complain about the share name games already being a valid system user name".
Where would be the benefit, the user is still told almost the very same things?

And worst case if you or anyone else later on convinces (or implements and submits) upstream samba to reconsider and allow to add such shares through `net usershare add` then the UI would still block it despite it would now work. That feels even more wrong.

.... just to explain why I didn't assign the desktop team

Revision history for this message
8765pu (8765pukxbhc876y-deactivatedaccount) wrote :

> It would then tell the user "I'm not going to send this request to samba as it will complain about the share name games already being a valid system user name".

You wouldn't tell the user that. If the desired result is possible by avoiding using `net usershare` then by "isolate" I mean "perform the operation (create the share) another way". I don't mean "isolate" as in "artificially roadblock the user by choosing to perform the requested task with the specific tool that fails".

Here's the way that presumably would not fail according to an earlier comment:

> I think you *can* setup a share named "games" by setting it up in smb.conf

If that is possible then there's no need to inconvenience the user here. Just apply the workaround, asking for confirmation/authentication if needed.

And you wouldn't block any later additions in samba, since you only perform the alternative solution if the first one returned this error.

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for samba (Ubuntu) because there has been no activity for 60 days.]

Changed in samba (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.