I only added vers=1.0 to the client's cifs options. Then everything
worked as in 17.04. I didn't need the sec setting.
https://unix.stackexchange.com/questions/399378/samba-mount-issue-under-
ubuntu-17-10
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
[Expired for samba (Ubuntu) because there has been no activity for 60
days.]
** Changed in: samba (Ubuntu)
Status: Incomplete => Expired
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1703490
sec= in mount.cifs is a client setting, I was quoting the mount.cifs
manpage where it says when that changed defaults in the (client
machine's) kernel.
Either way, I believe the solution to what you reported is in the first
paragraph of comment #21.
--
You received this bug notification because
sec= in mount.cifs is a client setting, I was quoting the mount.cifs
manpage where it says when that changed defaults in the (client
machine's) kernel.
Either way, I believe the solution to what you reported is in the first
paragraph of comment #21.
--
You received this bug notification because
If I was using sec=ntlm to connect successfully to a xenial server,
clearly that server did not have a kernel that had a problem with ntlm
security. A long time after trusty was released.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Ok, so you either change your clients to use "sec=ntlmssp", or change
"ntlm auth" on the server to "yes" as explained by @metze in comment
#17.
This sec= setting in mount.cifs also changed defaults. From its manpage:
"The default in mainline kernel versions prior to v3.8 was sec=ntlm. In v3.8,
Ok, so you either change your clients to use "sec=ntlmssp", or change
"ntlm auth" on the server to "yes" as explained by @metze in comment
#17.
This sec= setting in mount.cifs also changed defaults. From its manpage:
"The default in mainline kernel versions prior to v3.8 was sec=ntlm. In v3.8,
I have already confirmed this in testing.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1703490
Title:
Unable to mount network volume on 17.10 Samba server
To manage notifications about this bug
Can you try Stefan's suggestion from comment #17 please?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to samba in Ubuntu.
https://bugs.launchpad.net/bugs/1703490
Title:
Unable to mount network volume on 17.10 Samba server
To manage
Can you try Stefan's suggestion from comment #17 please?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1703490
Title:
Unable to mount network volume on 17.10 Samba server
To manage notifications
So based on some tinkering, the option sec=ntlm seems to be the issue.
Now the 16.04 servers accept this and the 17.10 servers spew, so there
has to be some difference in the handling of security settings between
the two.
On 13/07/17 04:53, Andreas Hasenack wrote:
> It could be that, in the
Use sec=ntlmssp and it will work again.
On the server the default for "ntlm auth" changed from yes to no.
So it will only accept ntlmv2 via ntlmssp anymore.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
OK here is a fstab from one of my PCs running 17.10 and it tries to
mount shares from two different computers:
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
It could be that, in the case where /etc/fstab is used, there are extra
options being passed to mount.cifs and that is what is causing the
difference in behaviour.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
It could be that, in the case where /etc/fstab is used, there are extra
options being passed to mount.cifs and that is what is causing the
difference in behaviour.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to samba in Ubuntu.
It worked on the first 16-04 client I tried
I have quite a few 16.04 clients I was testing it on (VMs). It will take
me a while to go through them all and check which ones were having the
problems and what command was tried. I think they are mostly doing the
mount in /etc/fstab
On 13/07/17
IP addresses work fine too.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to samba in Ubuntu.
https://bugs.launchpad.net/bugs/1703490
Title:
Unable to mount network volume on 17.10 Samba server
To manage notifications about this bug
IP addresses work fine too.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1703490
Title:
Unable to mount network volume on 17.10 Samba server
To manage notifications about this bug go to:
I never use server names, I always use IP addresses. I don't even know
what the name of the server is.
On 13/07/17 00:56, Andreas Hasenack wrote:
> Sorry about your frustration, we are just trying to narrow it down. It
> could be that something in artful's samba changed and that thunar needs
>
Here is what I got with xfce on 16.04 using thunar. Just the home share
is read-only, as expected.
** Attachment added: "thunar-xfce.png"
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1703490/+attachment/4913443/+files/thunar-xfce.png
--
You received this bug notification because you
Here is what I got with xfce on 16.04 using thunar. Just the home share
is read-only, as expected.
** Attachment added: "thunar-xfce.png"
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1703490/+attachment/4913443/+files/thunar-xfce.png
--
You received this bug notification because you
Sorry about your frustration, we are just trying to narrow it down. It
could be that something in artful's samba changed and that thunar needs
to adapt, for example.
We need to determine why this test case that you mentioned when opening
the bug doesn't work:
"""
16.04 client mount.cifs to 17.10
Sorry about your frustration, we are just trying to narrow it down. It
could be that something in artful's samba changed and that thunar needs
to adapt, for example.
We need to determine why this test case that you mentioned when opening
the bug doesn't work:
"""
16.04 client mount.cifs to 17.10
Whatever
The furtherest I have got is changing the cifs version number in
mount.cifs will mount the maps share read only instead of not mounting
it at all. I still haven't got to a point where it is mounted for full
read write access.
Smbclient looks like ftp, how are you going to open read
Let's try to narrow it down to a simple test case involving smbclient
and/or mount.cifs.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to samba in Ubuntu.
https://bugs.launchpad.net/bugs/1703490
Title:
Unable to mount network volume
Let's try to narrow it down to a simple test case involving smbclient
and/or mount.cifs.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1703490
Title:
Unable to mount network volume on 17.10 Samba
On 12/07/17 03:03, Andreas Hasenack wrote:
> I tried your shares, and they seem to work as expected. Note that
> [Homes] is read only (default for "read only" is "yes"), so you won't be
> able to write to Homes or even Maps under it while connected to Homes,
> but if you connect to Maps, then you
I tried your shares, and they seem to work as expected. Note that
[Homes] is read only (default for "read only" is "yes"), so you won't be
able to write to Homes or even Maps under it while connected to Homes,
but if you connect to Maps, then you can:
oot@nsn7:~# for d in Home Maps Media; do
I tried your shares, and they seem to work as expected. Note that
[Homes] is read only (default for "read only" is "yes"), so you won't be
able to write to Homes or even Maps under it while connected to Homes,
but if you connect to Maps, then you can:
oot@nsn7:~# for d in Home Maps Media; do
output of mount command on client 192.168.1.173:
//192.168.1.116/maps on /mnt/share/mainpc/maps type cifs
Using the example given
To specify a different version, mount the cifs fileysystem like this:
root@nsn7:~# mount //10.0.5.55/data /data -o user=ubuntu,vers=2.0
Password for ubuntu@//10.0.5.55/data: **
so far has resulted in read only access to a share that is specified as
read/write.
patrick@MainPC:/etc/X11$ sudo smbstatus
[sudo] password for patrick:
Samba version 4.5.8-Ubuntu
PID Username Group Machine
Protocol Version Encryption Signing
Thanks for filing this bug in Ubuntu.
Could you please share your /etc/samba/smb.conf on that 17.10 server?
The output of "testparm -s" would be best.
I tried the same here and could mount the share just fine from xenial.
Maybe you restricted the smb protocol to higher versions? mount.cifs
will
Thanks for filing this bug in Ubuntu.
Could you please share your /etc/samba/smb.conf on that 17.10 server?
The output of "testparm -s" would be best.
I tried the same here and could mount the share just fine from xenial.
Maybe you restricted the smb protocol to higher versions? mount.cifs
will
34 matches
Mail list logo
