Some observations:
I can reproduce the original error when I use caja to create a share of
my Public folder ( /home/tester/Public ).
The error log at /home/tester/Public/log.net is:
"net usershare add: share name /home/tester/public contains invalid
characters (any of %<>*?|/\+=;:",)"
There
This is perhaps outside the responsibility of this venue to answer but I
did an apt update on Ubuntu 22.04 today and there are now two wsdd
packages:
wsdd2: 1.8.6+dfsg-3
wdd: 2:0.7.0-1
In the limited tests I have done they both work. I do not know what
would happen if both of them were installed
Since my last post I starting testing Ubuntu 22.04 and noticed there is
a package wsdd2. https://packages.ubuntu.com/jammy/net/wsdd2
It's in jammy/universe. I installed it and I can connect to it from
Win11 as WSD.
So now I'm confused. Which one is which. They are not the same package
but do
I tested this on Ubuntu 20.04 and Mint 20 and it works as advertised. I
don't see a path to 22.04 yet but it may be too soon.
I hope there is time to include it into the Ubuntu 22.04 release as
either a dependency of the samba package itself or at least as an
available separate install within the
And for other folks:
https://askubuntu.com/questions/1328978/ubuntu-samba-copied-files-
inaccessible
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1872476
Title:
Shared files are shown as folders
So I duplicated the steps in #70 and was able to reproduce the "type:
directory" problem.
Then I edited smb.conf and set "store dos attributes = No" in the
[global] section and restarted smbd.
If I redo the steps in #70 the issue is resolved resulting in: "type:
regular"
"store dos attributes"
What is missing from your description is what happens after your system
has finished rebooting.
Does the share mount when you issue one of the following commands:
sudo mount -a
Or:
sudo mount /mnt/server_e
Both of those commands will reference the fstab declaration.
If it does this may not
More of an FYI but you will get a "Software caused connection abort"
error anytime Nautilus tries to connect to a SMB / Samba server that
only uses SMB1.
There is no SMB1 ( NT1 ) on the client ( or server ) side in Ubuntu20.
There is in Ubuntu 18.
SO either enable SMB2/SMB3 on the diskstation or
"laurent@laurent-iMac:~$ smbclient //192.168.1.1/USB1
...
...
protocol negotiation failed: NT_STATUS_CONNECTION_DISCONNECTED"
You are getting a "protocol negotiation failed" error because the server
can only be accessed with SMB1 ( NT1 ) and there is no SMB1 ( NT1 ) in
the version of samba that
Public bug reported:
Please add WS-Discovery ( WSD ) support for Windows Samba server
discovery.
Windows 10 disables the smbv1 client dialect on new builds and this in
turn disables NetBIOS host discovery in its File manager. Configured
this way Win10 will never be able to browse the network and
@seb128, If the samba share was created on Ubuntu Server and not on
Ubuntu Desktop then without the fix you will not see the samba server
through Nautilus.
That's because Ubuntu Server does not install avahi-daemon by default.
Once installed it's visible outside of "Windows Network" because of
I understand.
I would however like to make a final note about Linux to Linux samba use
- at least in a home network.
If the server is running Ubuntu 17.10 or later ( with avahi-daemon
installed ) this bug is not relevant because the samba client isn't
using gvfsd-smb-browse. The sever
Here's a different perspective. Accessing the Win10 machine again:
tester@vub1904:~$ smbclient -L vwin10 -U smbuser
Unable to initialize messaging context
Enter WORKGROUP\smbuser's password:
Sharename Type Comment
- ---
ADMIN$
smbclient -L, "gio mount smb://server/share ', even just specifying
smb://server/share in the location bar in Nautilus works just like you
would expect.
It's only the gvfsd-smb-browse process that's messed up.
As far as it being a related but different problem Well I reckon it
all depends
Your reference to the Linux Samba Server command: smbstatus got me
thinking what would happen if I disabled NT1 on a Linux Samba server by
stipulating "server min protocol = SMB2" and using Windows Network > ...
to connect.
The exact same thing happens as when trying to connect to a Win10
machine
My post concerns Ubuntu Disco. I'm guessing Win10 sees the SMBv1
connection, rejects it outright, and never gets to the protocol
negotiation phase.
As I said this only involves the gvfsd-smb-browse process: Nautilus >
Other Locations > Windows Network > Workgroup
If I use Connect to Server
There is an issue with this fix that makes it impossible to access a
Windows 10 machine that has disabled SMB1 ( NT1 ):
smb-network: g_vfs_backend_smb_browse_init: default workgroup = 'NULL'
smb-network: Added new job source 0x55ebe2dd53d0 (GVfsBackendSmbBrowse)
smb-network: Queued new job
Just a side note folks but there's two SMBv1's involved here and both
are mentioned in this bug report.
There's the server part ( server min protocol ).
But there is also a samba client part ( client min / max protocol ) and
that's where the fun starts.
Nautilus uses gvfs which uses libsmblient
To paraphrase a former US President it all depends on what the
definition of "fixed" is.
In Xubuntu 17.04 Beta1 which uses 4.5.4 of samba it does appear to be
fixed. But for Xubuntu 16.10 ( 4.4.5 ), Xubuntu 16.04 ( 4.3.11 ), and
Xubuntu 14.04 ( 4.3.11 ) not so much.
Now the last two are LTS
If you don't want to muck about with the internals of the macOS box you
can also bypass smbclient on the Linux box and connect to it with a CIFS
mount:
sudo mount -t cifs //server/share /mountpoint -o
username=xxx,password=yyy,uid=1000,nounix
--
You received this bug notification because you
In the #=== Share Definitions
=== section of smb.conf exists the original [homes]
share from Debian which looks like this but is scattered throughout the
section:
[homes]
comment = Home Directories
browseable = no
read only = yes
create mask =
In the #=== Share Definitions
=== section of smb.conf exists the original [homes]
share from Debian which looks like this but is scattered throughout the
section:
[homes]
comment = Home Directories
browseable = no
read only = yes
create mask =
22 matches
Mail list logo
