Nautilus: Windows Network discovery results in error
Open, In Progress, HighPublic

Description

I did a fresh install of Solus. When opening nautilus -> other locations -> windows network I get following error message:

"Unable to access location - Failed to retrieve list from server: No such file directory"

In previous versions I could browse through my network shares. Even the connect button in the lower right corner is always disabled. No matter what I set in the server adress textbox.

panhans created this task.Oct 21 2016, 5:11 PM
JoshStrobl edited projects, added Software; removed Triage Team.Oct 28 2016, 9:25 PM
DataDrake moved this task from Backlog to Package Fixes on the Software board.Oct 31 2016, 8:08 PM
JoshStrobl triaged this task as "High" priority.
JoshStrobl added a subscriber: JoshStrobl.

I'll be setting up Samba on my local server early next week to validate and fix this. Marking self as assignee and considering this a high-priority issue.

tadcan added a subscriber: tadcan.Jul 20 2017, 7:24 PM

@JoshStrobl I was looking at my journal in plasma (for things I might need to fix), A couple of things came up r.e. samba that may be useful.

kf5.kio.core: We got some errors while running 'net usershare info'
kf5.kio.core: "Failed to init messaging context\n"
kf5.kio.core: "mkdir failed on directory /var/lock/samba: Permission denied\nFailed to init messaging context\n"

Which lead me to this patch as a potential fix for something relevant to the "Failed to init messaging context" : https://attachments.samba.org/attachment.cgi?id=13264

But the lock dir appears to be in addition to that issue.

Okra added a subscriber: Okra.Sep 29 2017, 7:31 PM

Just an update on this: I bought a new network card for the server and worked out a network topology for me to apply here (thanks to @ermo). Once that arrives, I'll get Samba all set up and we can start investigating this.

Justin added a subscriber: Justin.Fri, Nov 3, 11:05 AM

See this works on all of my Solus installs, I can browse the Windows Network as well as WORKGROUP and shares on both my router and server.

Maybe related to this bug: I cannot connect to a Windows printer via samba using the settings -> devices -> printers 'Add a printer' tool.

clauded added a subscriber: clauded.Sat, Nov 4, 4:28 PM

On my Solus install, I can't display Windows networks in Nautilus (works ok in Ubuntu however) : when opening nautilus -> other locations -> windows network, I get an empty list. When I use the IP address of my Samba share, it works fine however (smb://192.168.0.1).

When I run manually /usr/lib64/gvfs/gvfsd-smb-browse (after a fresh login without opening Nautilus), I get :
Kerberos auth with 'claude@WORKGROUP' (WORKGROUP\claudio) to access '192.168.0.1' not possible

My share is accessible for anonymous users. I think the workgroup named 'WORKGROUP' is discovered with broadcasting but gvfs tries to authenticate with my user name and fails. It should try anonymous login first so it could at least show WORKGROUP in Nautilus.

This shows how resolution is done:

smbtree -d3

lp_load_ex: refreshing parameters
Initialising global parameters
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Processing section "[global]"
added interface enp9s0 ip=2607:fa48:6ee4:3070::729 bcast= netmask=ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
added interface enp9s0 ip=2607:fa48:6ee4:3070:9ca0:2607:17aa:7dee bcast= netmask=ffff:ffff:ffff:ffff::
added interface enp9s0 ip=fd93:1497:dfef::729 bcast= netmask=ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
added interface enp9s0 ip=fd93:1497:dfef:0:1170:ad38:6a5c:8885 bcast= netmask=ffff:ffff:ffff:ffff::
added interface enp9s0 ip=192.168.0.12 bcast=192.168.0.255 netmask=255.255.255.0
added interface virbr0 ip=192.168.122.1 bcast=192.168.122.255 netmask=255.255.255.0
tdb(/var/cache/samba/gencache.tdb): tdb_open_ex: could not open file /var/cache/samba/gencache.tdb: Permission non accordée
Connecting to 192.168.0.1 at port 445
got OID=1.3.6.1.4.1.311.2.2.10
GENSEC backend 'gssapi_spnego' registered
GENSEC backend 'gssapi_krb5' registered
GENSEC backend 'gssapi_krb5_sasl' registered
GENSEC backend 'spnego' registered
GENSEC backend 'schannel' registered
GENSEC backend 'naclrpc_as_system' registered
GENSEC backend 'sasl-EXTERNAL' registered
GENSEC backend 'ntlmssp' registered
GENSEC backend 'ntlmssp_resume_ccache' registered
GENSEC backend 'http_basic' registered
GENSEC backend 'http_ntlm' registered
GENSEC backend 'krb5' registered
GENSEC backend 'fake_gssapi_krb5' registered
Got challenge flags:
Got NTLMSSP neg_flags=0x628a8215
NTLMSSP: Set final flags:
Got NTLMSSP neg_flags=0x62008215
NTLMSSP Sign/Seal - Initialising with flags:
Got NTLMSSP neg_flags=0x62008215
WORKGROUP
Connecting to 192.168.0.1 at port 445
got OID=1.3.6.1.4.1.311.2.2.10
Got challenge flags:
Got NTLMSSP neg_flags=0x628a8215
NTLMSSP: Set final flags:
Got NTLMSSP neg_flags=0x62008215
NTLMSSP Sign/Seal - Initialising with flags:
Got NTLMSSP neg_flags=0x62008215
\\TPLINK
Connecting to fd93:1497:dfef::1 at port 445
got OID=1.3.6.1.4.1.311.2.2.10
Got challenge flags:
Got NTLMSSP neg_flags=0x628a8215
NTLMSSP: Set final flags:
Got NTLMSSP neg_flags=0x62008215
NTLMSSP Sign/Seal - Initialising with flags:
Got NTLMSSP neg_flags=0x62008215

		\\TPLINK\IPC$           	IPC Service 
		\\TPLINK\public
clauded added a comment.EditedSat, Nov 11, 12:00 AM

I found this thread and it might explain why I can't browse Windows network but still be able to browse a share when I specify the server location (ex. smb://server/smb-share) in Nautilus : https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1697817

One more thing : in my Samba server config, I had 'max protocol = SMB2'. Browsing was ok with WinXP, Win7 and old version of Ubuntu and Solus. Getting rid of this parameter in Samba, now browsing with Solus works fine.

ermo added a comment.Fri, Nov 17, 9:45 PM

One more thing : in my Samba server config, I had 'max protocol = SMB2'. Browsing was ok with WinXP, Win7 and old version of Ubuntu and Solus. Getting rid of this parameter in Samba, now browsing with Solus works fine.

Yeah, I noticed in my logs that the kernel now defaults to SMB2.1 or later when mounting CIFS shares. I wouldn't be at all surprised if this was related to which SMB dialect is in use by default (but I haven't investigated it myself, so I can of course be way off base).

Just add this reference T4771 as it is linked to what you're discussing

ermo added a comment.EditedSun, Nov 19, 9:52 AM

So, the component responsible for broadcast Windows Network discovery is called gvfsd-smb-browse.

Last night during the stream, I experimented with downgrading samba to the latest 4.6.10 from Nov. 15th instead of the current 4.7.0 from Oct. 8th and rebuilt gvfs against it.

This resulted in Windows Network Discovery working again (my non-solus samba server is on kernel 4.13.x and is running samba 4.6.x)

I haven't tried with the newest 4.7.2 (also released on Nov. 15th).

But in any case samba needs an update due to a corruption issue (4.6.10), (4.7.2), and I would therefore suggest taking a step back from the bleeding edge and see what the other distros do re. gvfsd-smb-browse and samba 4.7.x, since the 4.6.x series is still supported and works out of the box.

To get debugging output, kill any existing gvfsd-smb-browse instances and, in a terminal, run:

GVFS_DEBUG=1 /usr/lib64/gvfs/gvfsd-smb-browse

@ermo which update for security ? I don't see anything !?
Or is it to disable SMB1 because the LTS kernel is still < 4.13 ?

I guess it worth trying to rebuild gvfs against samba 4.7.2 (I may do it be I first wait for D1248 to be accepted because I don't want to test things that may remain in the queue for still some time as there may be updates which will oblige me to recheck anyway).

ermo added a comment.Sun, Nov 19, 10:54 AM

Sorry, should have been _corruption_ issue (not security).

Correct me if I'm wrong but I see two issues related to SMB1:

  1. Kernel 4.13 disable SMB1 by default: cifs mount (in fstab for example) need an explicit option declaration (vers=1.0) to work against SMB1 shares.
  2. It's not clear why gvfs browsing works with 4.6 and not 4.7 : in 4.7 "client min protocol" hasn't changed, so it's still possible to connect to SMB1-only servers by default."

In all cases, browsing will never work if the server has disabled SMB1 (witch will be common in the future). In my case, my Samba server now has "server min protocol = SMB2" and browsing Windows network returns nothing. However, my Samba server appears by default in "Other locations" so I have something that is user friendly (I run kernel 4.13 by the way). I'd be curious to see how Windows 10 client reacts to browsing servers with and without SMB1 support...

One side note, Ubuntu 17.10 ships with Samba version 4.6. They've been ask by Microsoft to disable SMB1 by default but they have not made the decision yet.

JoshStrobl changed the task status from "Open" to "In Progress".Tue, Nov 21, 11:51 AM

@clauded Yea I ended up downgrading our Samba last night / this morning (idk, time) to 4.6.10. 4.7.x is a bit too ahead of the curb and I saw no indication that even unstable versions of gvfs would ensure Samba browsing would work correctly.

Also I should probably mark this as in progress, cause it is.

Can confirm that Samba is now functioning as intended with Samba 4.6.10. I won't close this issue yet however, since I still want to set some sane defaults for our Samba package / its configuration.

Personally, I got same results with the latest build of gvfs against Samba 4.6 : no Windows network browsing but browsing the server for shares is ok.
@JoshStrobl I'm curious to know the config of your Samba server and what was not working with 4.7.

kyrios123 rescinded a token.
kyrios123 awarded a token.

@clauded Here's my Samba configuration. Large thanks to @ermo for guiding me through Samba configuration.

Note: This is running on a Fedora Server, not Solus (cause ya know, it's not a server).

@JoshStrobl I did some testing with your config and here's some observations (tested on Samba server v3.6.25):

  1. client options are not relevant (unless your Fedora server is also a client of other Samba servers)
  2. IPC params seems to be only for Samba 4.x (so in my case, smbtree tells me I'm using NT1)
  3. to disable SMB1 (to be secure), one has to set "server min protocol" to SMB2 or SMB3 on the server
  4. I tested with SMB1 is enabled on the server but with my Solus WS (kernel 4.13 with Samba 4.6), I can't browse the Windows Network however my server is listed under Other locations and I can browse it. Same behavior with Ubuntu 16.04 btw.

When you say you "cant browse", is it the Windows Network?

I can browse my Samba via Windows Network in Files, Samba here being on my Fedora Server. None of the changes I made, as I said in my comment, were on Solus. The only thing I did to Samba was downgrade it to 4.6.10 and connect to my server.

ermo added a comment.Thu, Nov 23, 8:08 AM
This comment was removed by ermo.
ermo added a comment.EditedThu, Nov 23, 8:15 AM

@clauded:

I checked, and there are a bunch of bugs logged against gvfs for browsing against the Microsoft Windows implementation of SMB.

Chiefly, it seems that something happens if SPNEGO fails for gvfs when connecting to a Windows machine, which *might* make gvfs will just give up and crap out instead of falling back to another method (#582612, #582277) -- and yes, these are *old* bugs.

It is not clear to me what 'error 22' -- which is passed up the stack to the UI when trying to browse a Microsoft Windows-controlled workgroup with a non-default name -- really is?

Thus, this doesn't seem to be just samba, but rather the interaction betweem samba + gvfsd-smb-browse + microsoft's implementation?

We should probably capture gvfsd-smb-browse debug output will full libsmbclient output as well, which per the developer docs is done like this:

# It might be necessary to kill any existing gvfsd-smb-browse before running this.
#
# 4 and up is considered libsmbclient developer debug output.
# 
GVFS_DEBUG=1 GVFS_SMB_DEBUG=10 /usr/lib64/gvfs/gvfsd -r

Next step for me is to split my Windows 10 workstation out into another workgroup than my Fedora 4.6.x Samba server and see what gives -- I've currently got my Samba box configured to win the local master browser election when the two are in the same workgroup.

I can also confirm that if I set 'server min protocol' to anything higher than NT1 (NT1 is the newest version of the SMB1 protocol), smbtree -b -N shows no shares available (which likely applies to libsmbclient as used by gvfsd-smb-browse as well).

EDIT:

This is what the debug output says when I try to connect to my Windows box (truncated to only show the relevant parts -- prior to this, the connection is negotiated successfully):

NTLMSSP Sign/Seal - using NTLM1
 session setup ok
 tconx ok
IPC$ so ignore case sensitivity
smb-network: adding cached server 'BARNEY'\'IPC$', user 'WORKGROUP';'ermo' with data 0x7f0420019820
Server connect ok: //BARNEY/IPC$: 0x7f0420019820
num_setup=0, max_setup=0, param_total=40, this_param=40, max_param=8, data_total=0, this_data=0, max_data=65535, param_offset=92, param_pad=2, param_disp=0, data_offset=132, data_pad=0, data_disp=0
smb-network: do_mount - [smb://syvmileskoven; 0] dir = (nil), cancelled = 0, errno = [22] 'Invalid argument' 
smb-network: do_mount - (errno != EPERM && errno != EACCES), cancelled = 0, breaking
smb-network: send_reply(0x139b2c0), failed=1 (Failed to retrieve share list from server: Invalid argument)
Performing aggressive shutdown.
smb-network: purging server cache
Context 0x7f0420011c50 successfully freed

EDIT#2:

This is what the same section of debug output looks like when connecting to my Samba server:

NTLMSSP Sign/Seal - using NTLM1
 session setup ok
 tconx ok
IPC$ so ignore case sensitivity
smb-network: adding cached server 'DANTE'\'IPC$', user 'WORKGROUP';'ermo' with data 0x7f042001a9c0
Server connect ok: //DANTE/IPC$: 0x7f042001a9c0
num_setup=0, max_setup=0, param_total=39, this_param=39, max_param=8, data_total=0, this_data=0, max_data=65535, param_offset=92, param_pad=2, param_disp=0, data_offset=134, data_pad=3, data_disp=0
smb-network: do_mount - [smb://gremlinbytes; 0] dir = 0x7f04200042c0, cancelled = 0, errno = [17] 'File exists' 
smb-network: update_cache - updating...
smb-network: update_cache - done.
smb-network: do_mount - login successful, res = 1
smb-network: send_reply(0x139b230), failed=0 ()
(... output truncated for brevity ...)

EDIT#3:

It is probably worth mentioning that before gvfs can do anything with a resource, it needs to successfully mount it.

As you can see from the above log snippets, gvfs successfully mounts the Samba server IPC$ share but not the Microsoft server IPC$ share (these are the shares which list the available shared SMB resources on a server instance).

EDIT#4:

This is me trying to access my Windows SMB server with smbclient:

$ smbclient -d0 -N -L //barney/
Anonymous login successful
Domain=[BARNEY] OS=[Windows 10 Pro 16299] Server=[Windows 10 Pro 6.3]

	Sharename       Type      Comment
	---------       ----      -------
Error returning browse list: NT_STATUS_ACCESS_DENIED
Anonymous login successful
Domain=[BARNEY] OS=[Windows 10 Pro 16299] Server=[Windows 10 Pro 6.3]

	Server               Comment
	---------            -------

	Workgroup            Master
	---------            -------

The problem here (browsing anonymously) seems to be that Windows simply won't give access to the browse list by default?

My guess is that this is the error that gvfsd-smb-browse chokes on?

This is a slightly more verbose version of the above (-d3 vs -d0) -- notice how SPNEGO fails :

$ smbclient -d3 -N -L //barney/
lp_load_ex: refreshing parameters
Initialising global parameters
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Processing section "[global]"
added interface enp6s0 ip=192.168.1.224 bcast=192.168.1.255 netmask=255.255.255.0
added interface virbr0 ip=192.168.122.1 bcast=192.168.122.255 netmask=255.255.255.0
Client started (version 4.6.11).
tdb(/var/cache/samba/gencache.tdb): tdb_open_ex: could not open file /var/cache/samba/gencache.tdb: Permission denied
tdb(/run/lock/gencache_notrans.tdb): tdb_open_ex: could not open file /run/lock/gencache_notrans.tdb: No such file or directory
tdb(/var/cache/samba/gencache.tdb): tdb_open_ex: could not open file /var/cache/samba/gencache.tdb: Permission denied
tdb(/run/lock/gencache_notrans.tdb): tdb_open_ex: could not open file /run/lock/gencache_notrans.tdb: No such file or directory
resolve_lmhosts: Attempting lmhosts lookup for name barney<0x20>
resolve_wins: WINS server resolution selected and no WINS servers listed.
resolve_hosts: Attempting host lookup for name barney<0x20>
tdb(/var/cache/samba/gencache.tdb): tdb_open_ex: could not open file /var/cache/samba/gencache.tdb: Permission denied
tdb(/run/lock/gencache_notrans.tdb): tdb_open_ex: could not open file /run/lock/gencache_notrans.tdb: No such file or directory
Connecting to 192.168.1.100 at port 445
got OID=1.3.6.1.4.1.311.2.2.30
got OID=1.3.6.1.4.1.311.2.2.10
GENSEC backend 'gssapi_spnego' registered
GENSEC backend 'gssapi_krb5' registered
GENSEC backend 'gssapi_krb5_sasl' registered
GENSEC backend 'spnego' registered
GENSEC backend 'schannel' registered
GENSEC backend 'naclrpc_as_system' registered
GENSEC backend 'sasl-EXTERNAL' registered
GENSEC backend 'ntlmssp' registered
GENSEC backend 'ntlmssp_resume_ccache' registered
GENSEC backend 'http_basic' registered
GENSEC backend 'http_ntlm' registered
GENSEC backend 'krb5' registered
GENSEC backend 'fake_gssapi_krb5' registered
Got challenge flags:
Got NTLMSSP neg_flags=0x628a8215
NTLMSSP: Set final flags:
Got NTLMSSP neg_flags=0x62008215
NTLMSSP Sign/Seal - Initialising with flags:
Got NTLMSSP neg_flags=0x62008215
SPNEGO login failed: Logon failure
got OID=1.3.6.1.4.1.311.2.2.30
got OID=1.3.6.1.4.1.311.2.2.10
Got challenge flags:
Got NTLMSSP neg_flags=0x628a8215
NTLMSSP: Set final flags:
Got NTLMSSP neg_flags=0x62008a15
NTLMSSP Sign/Seal - Initialising with flags:
Got NTLMSSP neg_flags=0x62008a15
NTLMSSP Sign/Seal - Initialising with flags:
Got NTLMSSP neg_flags=0x62008a15
Anonymous login successful
Domain=[BARNEY] OS=[Windows 10 Pro 16299] Server=[Windows 10 Pro 6.3]

	Sharename       Type      Comment
	---------       ----      -------
Error returning browse list: NT_STATUS_ACCESS_DENIED
tdb(/var/cache/samba/gencache.tdb): tdb_open_ex: could not open file /var/cache/samba/gencache.tdb: Permission denied
tdb(/run/lock/gencache_notrans.tdb): tdb_open_ex: could not open file /run/lock/gencache_notrans.tdb: No such file or directory
tdb(/var/cache/samba/gencache.tdb): tdb_open_ex: could not open file /var/cache/samba/gencache.tdb: Permission denied
tdb(/run/lock/gencache_notrans.tdb): tdb_open_ex: could not open file /run/lock/gencache_notrans.tdb: No such file or directory
resolve_lmhosts: Attempting lmhosts lookup for name barney<0x20>
resolve_wins: WINS server resolution selected and no WINS servers listed.
resolve_hosts: Attempting host lookup for name barney<0x20>
tdb(/var/cache/samba/gencache.tdb): tdb_open_ex: could not open file /var/cache/samba/gencache.tdb: Permission denied
tdb(/run/lock/gencache_notrans.tdb): tdb_open_ex: could not open file /run/lock/gencache_notrans.tdb: No such file or directory
Connecting to 192.168.1.100 at port 139
got OID=1.3.6.1.4.1.311.2.2.30
got OID=1.3.6.1.4.1.311.2.2.10
Got challenge flags:
Got NTLMSSP neg_flags=0x628a8215
NTLMSSP: Set final flags:
Got NTLMSSP neg_flags=0x62008215
NTLMSSP Sign/Seal - Initialising with flags:
Got NTLMSSP neg_flags=0x62008215
SPNEGO login failed: Logon failure
got OID=1.3.6.1.4.1.311.2.2.30
got OID=1.3.6.1.4.1.311.2.2.10
Got challenge flags:
Got NTLMSSP neg_flags=0x628a8215
NTLMSSP: Set final flags:
Got NTLMSSP neg_flags=0x62008a15
NTLMSSP Sign/Seal - Initialising with flags:
Got NTLMSSP neg_flags=0x62008a15
NTLMSSP Sign/Seal - Initialising with flags:
Got NTLMSSP neg_flags=0x62008a15
Anonymous login successful
Domain=[BARNEY] OS=[Windows 10 Pro 16299] Server=[Windows 10 Pro 6.3]

	Server               Comment
	---------            -------

	Workgroup            Master
	---------            -------
ermo added a comment.EditedThu, Nov 23, 7:41 PM

So, I've attempted to map out some common use cases when browsing for Windows Networks via Nautilus.

1. The simplest case:

  • 1 Windows box w/share and 1 solus box.
  • Both members of the default WORKGROUP network.
  • No Samba server daemon running on the network.
  • Windows box is local master.

Result:

  • Windows box shows up directly in "+ Other Locations" in Nautilus.
  • When I click on it, I'm asked for credentials.
  • If click on the WORKGROUP icon and then on the Windows box icon, I'm asked for credentials.
  • User experience: A-OK

2. Same as 1, but with a Samba server running (linux home-server or small business network):

  • 1 Windows box. 1 Solus client. 1 Samba server (not running on solus client).
  • All three members of the default WORKGROUP network.
  • Samba server is local master.

Result:

  • Windows box and Samba server show up directly in "+ Other Locations" in Nautilus.
  • When I click on either, I'm asked for credentials/allowed through if guest access is enabled.
  • If I click on the WORKGROUP icon and then on the Windows box icon, I'm asked for credentials.
  • User experience: A-OK

3. Similar to 1, but using a non-default workgroup name:

  • 1 Windows box w/share and 1 solus box.
  • Both members of the TEST workgroup.
  • No Samba server daemon running on the network.
  • Windows box is local master.

Result:

  • Windows box doesn't show up by default in "+ Other Locations"
  • When I click on the TEST workgroup, I get the error dialog:
  • User experience: FAIL

4. Similar to 2, but with a non-default workgroup name:

  • 1 Windows box. 1 Solus client. 1 Samba server (not running on solus client).
  • All three members of the non-default TEST workgroup.
  • Samba box is local master.

Result:

  • Windows box doesn't show up directly in "+ Other Locations" in Nautilus.
  • When I click on the TEST workgroup icon, both Windows box and Samba server are listed.
  • When I click on either server, I can access it (asked for credentials/allowed to access guest shares).
  • User experience: A-OK

Conclusion:

The most common/default scenarios Just Work out of the box.

The Samba server-less, Windows SMB server controlled, non-default scenario sort of sucks. Further investigation warranted?

ermo added a comment.EditedFri, Nov 24, 9:29 AM

Hm. According to MS' own SMB owner, Ned Pyle, "Network Neighbourhood" broadcast browsing for shares relies on SMB1:

Explorer Network Browsing

The Computer Browser service relies on SMB1 in order to populate the Windows Explorer Network (aka “Network Neighborhood”). This legacy protocol is long deprecated, doesn’t route, and has limited security. Because it cannot function without SMB1, it is removed at the same time.

However, some customers still use the Explorer Network in home and small business workgroup environments to locate Windows computers. To continue using Explorer Network, you can perform the following steps on your Windows computers that no longer use SMB1:

  1. Start the “Function Discovery Provider Host” and “Function Discovery Resource Publication” services and set them to delayed start.
  1. When the user opens Network, they will be prompted to enable network discovery. Do so.
  1. Now all Windows devices within that subnet that have these settings in place will appear in Network for browsing. This uses the WS-DISCOVERY protocol. Check with your other vendors and manufacturers if their devices still do not appear in this browse list after Windows devices appear; it is likely they have this protocol disabled or only support SMB1.

    Note: we highly recommend you map drives and printers for your users instead of enabling this feature, which still requires searching and browsing for their devices. Mapped resources are easier for them to locate, require less training, and are safer to use, especially when provided automatically through group policy.

Thinking some more about this, it seems there's no good way to (re-)gain discoverability in Nautilus/gvfs for modern Windows hosts that have SMB1 disabled, unless:

  • The user manually enables the Windows WS-DISCOVERY protocol
  • Samba (and thus libsmbclient) supports the WS-DISCOVERY protocol
  • GNOME's gvfs is taught to also support the WS-DISCOVERY protocol

We should probably keep a close eye on what the Linux eco-system does here, as there are clearly some pretty nasty security implications involved with keeping SMB1 enabled by default on Solus.