Unable to mount network volume on 17.10 Samba server

Bug #1703490 reported by Patrick Dunford
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
samba (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

I have a computer with a new 17.10 installation, and I have network resources on it that I want to share to other computers on my network, using Samba. I set it up the same way with Samba as I did with the old 16.04 installation, but all the other computers on the network that are running Xubuntu can't connect to it like they did before.

The following are the user experiences of different computers in my network connecting to shared SMB resources on other computers:

16.04 client mount.cifs to 16.04 server: full access
16.04 client path run/user/1000/gvfs to 16.04 server: full access
17.10 client mount.cifs to 16.04 server: full access

16.04 client mount.cifs to 17.10 server: access denied error
17.10 client mount.cifs to 17.10 server: access denied error
16.04 client path run/user/1000/gvfs to 17.10 server: read only access
Windows 10 client explorer map drive to 17.10 server: full access

the server used to run 16.04 and is now running 17.10. It is the same computer and has the same network resources shared on it that it had when it was running 16.04.

The server installation of 17.10 was a clean install but the home folder was existing on a different volume and was remounted after the install.

As you can see a Windows 10 computer is the only computer in the network that can connect to the Samba share with full access and no apparent difference in the user experience.

Ubuntu Artful Aardvark (development branch) 17.10
apt-cache policy samba
samba:
  Installed: 2:4.5.8+dfsg-2ubuntu3
  Candidate: 2:4.5.8+dfsg-2ubuntu3
  Version table:
 *** 2:4.5.8+dfsg-2ubuntu3 500
        500 http://nz.archive.ubuntu.com/ubuntu artful/main amd64 Packages
        100 /var/lib/dpkg/status

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: samba 2:4.5.8+dfsg-2ubuntu3
ProcVersionSignature: Ubuntu 4.10.0-26.30-generic 4.10.17
Uname: Linux 4.10.0-26-generic x86_64
ApportVersion: 2.20.5-0ubuntu5
Architecture: amd64
CurrentDesktop: XFCE
Date: Tue Jul 11 13:25:40 2017
SambaClientRegression: Yes
SourcePackage: samba
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Patrick Dunford (kahukowhai) wrote :
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

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 use SMB1 by default, whereas windows 10 will use SMB2 or 3 (can't recall now).

You can check with "smbstatus" on the server which protocol the connected client is using:
root@15-89:~# smbstatus

Samba version 4.5.8-Ubuntu
PID Username Group Machine Protocol Version Encryption Signing
----------------------------------------------------------------------------------------------------------------------------------------
14179 ubuntu ubuntu 10.0.5.1 (ipv4:10.0.5.1:57260) NT1 - -

Service pid Machine Connected at Encryption Signing
---------------------------------------------------------------------------------------------
data 14179 10.0.5.1 Tue Jul 11 12:59:32 PM 2017 UTC - -
IPC$ 14179 10.0.5.1 Tue Jul 11 12:59:32 PM 2017 UTC - -

No locked files

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: ******

root@nsn7:~# cd /data

root@nsn7:/data# ls -l
total 1024
-rwxr-xr-x 1 root root 38 Jul 11 09:57 welcome.txt

root@nsn7:/data# cat welcome.txt
Welcome to the data share, developer.

root@nsn7:/data# echo bye > bye.txt
root@nsn7:/data# ls -la
total 2052
drwxr-xr-x 2 root root 0 Jul 11 10:02 .
drwxr-xr-x 34 root root 4096 Jul 11 09:59 ..
-rwxr-xr-x 1 root root 4 Jul 11 10:02 bye.txt
-rwxr-xr-x 1 root root 38 Jul 11 09:57 welcome.txt

And smbstatus on the server in this case (showing only the relevant line, for brevity):
14182 ubuntu ubuntu 10.0.5.1 (ipv4:10.0.5.1:57720) SMB2_02 - -

In any case, I can read and write to the share. This is my smb.conf. All default except for the removal of printer shares, and the addition of the [data] share:
[global]
 server string = %h server (Samba, Ubuntu)
 log file = /var/log/samba/log.%m
 max log size = 1000
 syslog = 0
 panic action = /usr/share/samba/panic-action %d
 usershare allow guests = Yes
 map to guest = Bad User
 obey pam restrictions = Yes
 pam password change = Yes
 passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
 passwd program = /usr/bin/passwd %u
 server role = standalone server
 unix password sync = Yes
 dns proxy = No
 idmap config * : backend = tdb

[data]
 comment = Data share
 path = /data
 read only = no
 browseable = true
 guest ok = no

Changed in samba (Ubuntu):
status: New → Incomplete
Revision history for this message
Patrick Dunford (kahukowhai) wrote : Re: [Bug 1703490] Re: Unable to mount network volume on 17.10 Samba server
Download full text (6.9 KiB)

patrick@MainPC:/etc/X11$ sudo smbstatus
[sudo] password for patrick:

Samba version 4.5.8-Ubuntu
PID Username Group Machine
Protocol Version Encryption Signing
----------------------------------------------------------------------------------------------------------------------------------------
9888 patrick patrick 192.168.1.173
(ipv4:192.168.1.173:39770) NT1 - -
18049 patrick patrick 192.168.1.192
(ipv4:192.168.1.192:49706) SMB3_11 - partial(AES-128-CMAC)
18046 patrick patrick 192.168.1.192
(ipv4:192.168.1.192:49700) SMB3_11 - partial(AES-128-CMAC)

Service pid Machine Connected at
Encryption Signing
---------------------------------------------------------------------------------------------
Media 18046 192.168.1.192 Tue Jul 11 23:25:00 2017 NZST
- -
Maps 18046 192.168.1.192 Tue Jul 11 23:25:00 2017 NZST
- -
Home 18046 192.168.1.192 Tue Jul 11 23:24:52 2017 NZST
- -
Maps 18049 192.168.1.192 Tue Jul 11 23:25:00 2017 NZST
- -
Maps 9888 192.168.1.173 Tue Jul 11 20:01:40 2017 NZST
- -

Locked files:
Pid Uid DenyMode Access R/W Oplock
SharePath Name Time
--------------------------------------------------------------------------------------------------
18046 1000 DENY_NONE 0x80 RDONLY NONE
/home/patrick/Maps . Tue Jul 11 23:25:09 2017
18049 1000 DENY_NONE 0x80 RDONLY NONE
/home/patrick/Maps . Tue Jul 11 23:25:09 2017
18046 1000 DENY_NONE 0x80 RDONLY NONE
/home/patrick/Media . Tue Jul 11 23:25:09 2017
18046 1000 DENY_NONE 0x80 RDONLY NONE
/home/patrick . Tue Jul 11 23:25:09 2017

192.168.1.192 is the Windows 10 client

192.168.1.173 is a Xubuntu 16.04 client.

However, smbstatus isn't showing anything about the clients that were
unable to mount a network resource (as to what version of CIFS they may
have attempted to use).

Computer 192.168.1.173 has been connected via /run/user/1000/gvfs which
on previous servers has been RW but with this 17.10 server is only RO
accessible.

patrick@MainPC:/etc/X11$ testparm
Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
WARNING: The "syslog" option is deprecated
Processing section "[printers]"
Processing section "[print$]"
Processing section "[Maps]"
Processing section "[Home]"
Processing section "[Media]"
Loaded services file OK.
Server role: ROLE_STANDALONE

Press enter to see a dump of your service definitions

# Global parameters
[global]
     server string = %h server (Samba, Ubuntu)
     log file = /var/log/samba/log.%m
     max log size = 1000
     syslog = 0
     panic action = /usr/share/samba/panic-action %d
     usershare allow guests = Yes
     map to guest = Bad User
     obey pam restrictions = Yes
     pam password change = Yes
     passwd chat =...

Read more...

Revision history for this message
Patrick Dunford (kahukowhai) wrote :

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.

Still testing with different clients.

Revision history for this message
Patrick Dunford (kahukowhai) wrote :
Download full text (3.4 KiB)

output of mount command on client 192.168.1.173:

//192.168.1.116/maps on /mnt/share/mainpc/maps type cifs
(rw,relatime,vers=2.0,sec=ntlmssp,cache=strict,username=patrick,domain=MAINPC,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.1.116,file_mode=0755,dir_mode=0755,nounix,serverino,mapposix,rsize=65536,wsize=65536,actimeo=1,user=patrick)

192.168.1.116 is the server of course

On 12/07/17 01:05, Andreas Hasenack wrote:
> 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 use SMB1 by default, whereas windows 10 will use SMB2 or 3 (can't
> recall now).
>
> You can check with "smbstatus" on the server which protocol the connected client is using:
> root@15-89:~# smbstatus
>
> Samba version 4.5.8-Ubuntu
> PID Username Group Machine Protocol Version Encryption Signing
> ----------------------------------------------------------------------------------------------------------------------------------------
> 14179 ubuntu ubuntu 10.0.5.1 (ipv4:10.0.5.1:57260) NT1 - -
>
> Service pid Machine Connected at Encryption Signing
> ---------------------------------------------------------------------------------------------
> data 14179 10.0.5.1 Tue Jul 11 12:59:32 PM 2017 UTC - -
> IPC$ 14179 10.0.5.1 Tue Jul 11 12:59:32 PM 2017 UTC - -
>
> No locked files
>
> 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: ******
>
> root@nsn7:~# cd /data
>
> root@nsn7:/data# ls -l
> total 1024
> -rwxr-xr-x 1 root root 38 Jul 11 09:57 welcome.txt
>
> root@nsn7:/data# cat welcome.txt
> Welcome to the data share, developer.
>
> root@nsn7:/data# echo bye > bye.txt
> root@nsn7:/data# ls -la
> total 2052
> drwxr-xr-x 2 root root 0 Jul 11 10:02 .
> drwxr-xr-x 34 root root 4096 Jul 11 09:59 ..
> -rwxr-xr-x 1 root root 4 Jul 11 10:02 bye.txt
> -rwxr-xr-x 1 root root 38 Jul 11 09:57 welcome.txt
>
>
> And smbstatus on the server in this case (showing only the relevant line, for brevity):
> 14182 ubuntu ubuntu 10.0.5.1 (ipv4:10.0.5.1:57720) SMB2_02 - -
>
> In any case, I can read and write to the share. This is my smb.conf. All default except for the removal of printer shares, and the addition of the [data] share:
> [global]
> server string = %h server (Samba, Ubuntu)
> log file = /var/log/samba/log.%m
> max log size = 1000
> syslog = 0
> panic action = /usr/share/samba/panic-action %d
> usershare allow guests = Yes
> map to guest = Bad User
> obey pam restrictions = Yes
> pam password change = Yes
> passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
> pass...

Read more...

Revision history for this message
Andreas Hasenack (ahasenack) 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 can:

oot@nsn7:~# for d in Home Maps Media; do mount //10.0.5.55/$d /patrick/$d -o user=patrick,password=patrick,vers=1.0; done
root@nsn7:~# cd /patrick/Home/
root@nsn7:/patrick/Home# touch hello-there
touch: cannot touch 'hello-there': Permission denied
root@nsn7:/patrick/Home# cd Maps
root@nsn7:/patrick/Home/Maps# touch hello-there
touch: cannot touch 'hello-there': Permission denied
root@nsn7:/patrick/Home/Maps# cd /patrick/Maps/
root@nsn7:/patrick/Maps# touch hello-there
root@nsn7:/patrick/Maps# cd /patrick/Home/Maps/
root@nsn7:/patrick/Home/Maps# ll
total 0
drwxr-xr-x+ 2 1001 1002 0 Jul 11 11:53 ./
drwxr-xr-x+ 4 1001 1002 0 Jul 11 11:50 ../
-rw-r--r--+ 1 1001 1002 0 Jul 11 11:53 hello-there

Note that Home is listed as rw, but it's read-only enforced on the server:
root@nsn7:~# mount -t cifs
//10.0.5.55/Home on /patrick/Home type cifs (rw,relatime,vers=1.0,cache=strict,username=patrick,domain=15-89,uid=0,noforceuid,gid=0,noforcegid,addr=10.0.5.55,unix,posixpaths,serverino,mapposix,acl,rsize=1048576,wsize=65536,actimeo=1,user=patrick)
//10.0.5.55/Maps on /patrick/Maps type cifs (rw,relatime,vers=1.0,cache=strict,username=patrick,domain=15-89,uid=0,noforceuid,gid=0,noforcegid,addr=10.0.5.55,unix,posixpaths,serverino,mapposix,acl,rsize=1048576,wsize=65536,actimeo=1,user=patrick)
//10.0.5.55/Media on /patrick/Media type cifs (rw,relatime,vers=1.0,cache=strict,username=patrick,domain=15-89,uid=0,noforceuid,gid=0,noforcegid,addr=10.0.5.55,unix,posixpaths,serverino,mapposix,acl,rsize=1048576,wsize=65536,actimeo=1,user=patrick)

A few more questions:

a) I don't understand your mentioning of "run/user/1000/gvfs", how is that involved?

b) do you have usershares set? try:
sudo net usershare list -l

c) have you tried smbclient?

d) are there other filesystems involved in these shares and their mountpoints?

e) Can we narrow down which shares are not working, out of your 3? Home, Maps, Media? Or all of them, when contacted with a xenial samba cifs (or smbclient)?

My cifs-utils package on xenial is at version 2:6.4-1ubuntu1.1, and my samba packages are:
# dpkg-query -W samba-common samba-common-bin samba-libs smbclient
samba-common 2:4.3.11+dfsg-0ubuntu0.16.04.8
samba-common-bin 2:4.3.11+dfsg-0ubuntu0.16.04.8
samba-libs:amd64 2:4.3.11+dfsg-0ubuntu0.16.04.8
smbclient 2:4.3.11+dfsg-0ubuntu0.16.04.8

Revision history for this message
Patrick Dunford (kahukowhai) wrote :
Download full text (3.3 KiB)

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 can:
>
> oot@nsn7:~# for d in Home Maps Media; do mount //10.0.5.55/$d /patrick/$d -o user=patrick,password=patrick,vers=1.0; done
> root@nsn7:~# cd /patrick/Home/
> root@nsn7:/patrick/Home# touch hello-there
> touch: cannot touch 'hello-there': Permission denied
> root@nsn7:/patrick/Home# cd Maps
> root@nsn7:/patrick/Home/Maps# touch hello-there
> touch: cannot touch 'hello-there': Permission denied
> root@nsn7:/patrick/Home/Maps# cd /patrick/Maps/
> root@nsn7:/patrick/Maps# touch hello-there
> root@nsn7:/patrick/Maps# cd /patrick/Home/Maps/
> root@nsn7:/patrick/Home/Maps# ll
> total 0
> drwxr-xr-x+ 2 1001 1002 0 Jul 11 11:53 ./
> drwxr-xr-x+ 4 1001 1002 0 Jul 11 11:50 ../
> -rw-r--r--+ 1 1001 1002 0 Jul 11 11:53 hello-there
>
>
> Note that Home is listed as rw, but it's read-only enforced on the server:
> root@nsn7:~# mount -t cifs
> //10.0.5.55/Home on /patrick/Home type cifs (rw,relatime,vers=1.0,cache=strict,username=patrick,domain=15-89,uid=0,noforceuid,gid=0,noforcegid,addr=10.0.5.55,unix,posixpaths,serverino,mapposix,acl,rsize=1048576,wsize=65536,actimeo=1,user=patrick)
> //10.0.5.55/Maps on /patrick/Maps type cifs (rw,relatime,vers=1.0,cache=strict,username=patrick,domain=15-89,uid=0,noforceuid,gid=0,noforcegid,addr=10.0.5.55,unix,posixpaths,serverino,mapposix,acl,rsize=1048576,wsize=65536,actimeo=1,user=patrick)
> //10.0.5.55/Media on /patrick/Media type cifs (rw,relatime,vers=1.0,cache=strict,username=patrick,domain=15-89,uid=0,noforceuid,gid=0,noforcegid,addr=10.0.5.55,unix,posixpaths,serverino,mapposix,acl,rsize=1048576,wsize=65536,actimeo=1,user=patrick)
>
> A few more questions:
>
> a) I don't understand your mentioning of "run/user/1000/gvfs", how is
> that involved?
In Thunar, if you type smb://mainpc/maps into the address bar then it
automounts to /run/user/1000/gvfs/smb-share:server=mainpc,share=maps,
this is a built in behaviour of the file manager Thunar on Xubuntu
(assuming your user account id is 1000)
>
> b) do you have usershares set? try:
> sudo net usershare list -l
No output from this command
>
> c) have you tried smbclient?
Not yet
>
> d) are there other filesystems involved in these shares and their
> mountpoints?
>
> e) Can we narrow down which shares are not working, out of your 3? Home,
> Maps, Media? Or all of them, when contacted with a xenial samba cifs (or
> smbclient)?
I am primarily testing the share Maps which should be fully read/write
If I attempt to mount myself using mount.cifs or the automount in
Thunar (smb://mainpc/maps) the most I can get is read only access.

Most of the time I am mounting shares in fstab and the usual outcome is
permission denied error 13 and no mount at all (not even read only)

>
> My cifs-utils package on xenial is at version 2:6.4-1ubuntu1.1, and my samba packages are:
> # dpkg-query -W samba-common samba-common-bin samba-libs smbclient
> samba-common 2:4.3.11+dfsg-0ubuntu...

Read more...

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Let's try to narrow it down to a simple test case involving smbclient and/or mount.cifs.

Revision history for this message
Patrick Dunford (kahukowhai) wrote :

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 and write files
over that, if the software expects it to be mapped to a folder on the
computer so it looks just like a local file.

On 12/07/17 06:29, Andreas Hasenack wrote:
> Let's try to narrow it down to a simple test case involving smbclient
> and/or mount.cifs.
>

Revision history for this message
Andreas Hasenack (ahasenack) 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 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 server: access denied error
"""

This doesn't involve thunar and is bare bones cifs/samba.

Please try the following on this 16.04 client. Adjust username if needed, and replace "<artful-server>" with your artful server's IP address:

sudo mkdir -p /artful/{Home,Maps,Media}
for d in Home Maps Media; do sudo mount //<artful-server>/$d /artful/$d -o username=patrick; done

If they get mounted, check what you can do in each /artful/* directory in terms of read/write.

If the above works, then I need to know the exact commands you tried for the above test case you tried and that failed. I suppose it's whatever you did to get to the mounted share you showed in comment #5, and then which read/write commands you tried and their outcome.

Thanks!

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Here is what I got with xfce on 16.04 using thunar. Just the home share is read-only, as expected.

Revision history for this message
Patrick Dunford (kahukowhai) wrote :

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
> 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 server: access denied error
> """
>
> This doesn't involve thunar and is bare bones cifs/samba.
>
> Please try the following on this 16.04 client. Adjust username if
> needed, and replace "<artful-server>" with your artful server's IP
> address:
>
> sudo mkdir -p /artful/{Home,Maps,Media}
> for d in Home Maps Media; do sudo mount //<artful-server>/$d /artful/$d -o username=patrick; done
>
> If they get mounted, check what you can do in each /artful/* directory
> in terms of read/write.
>
> If the above works, then I need to know the exact commands you tried for
> the above test case you tried and that failed. I suppose it's whatever
> you did to get to the mounted share you showed in comment #5, and then
> which read/write commands you tried and their outcome.
>
> Thanks!
>

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

IP addresses work fine too.

Revision history for this message
Patrick Dunford (kahukowhai) wrote :

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 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
> 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 server: access denied error
> """
>
> This doesn't involve thunar and is bare bones cifs/samba.
>
> Please try the following on this 16.04 client. Adjust username if
> needed, and replace "<artful-server>" with your artful server's IP
> address:
>
> sudo mkdir -p /artful/{Home,Maps,Media}
> for d in Home Maps Media; do sudo mount //<artful-server>/$d /artful/$d -o username=patrick; done
>
> If they get mounted, check what you can do in each /artful/* directory
> in terms of read/write.
>
> If the above works, then I need to know the exact commands you tried for
> the above test case you tried and that failed. I suppose it's whatever
> you did to get to the mounted share you showed in comment #5, and then
> which read/write commands you tried and their outcome.
>
> Thanks!
>

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

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.

Revision history for this message
Patrick Dunford (kahukowhai) wrote :

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
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sdb1 during installation
UUID=0887068e-fc83-4a98-a90f-ccbfdecd8728 / ext4
errors=remount-ro 0 1
# /home was on /dev/sdc1 during installation
UUID=b6c98b89-941b-4e36-b91b-f011633ae70d /home ext4
defaults 0 2
/swapfile none swap
sw 0 0
//192.168.1.173/media /mnt/share/mediapc/media cifs
credentials=/home/patrick/.smbcredentials,iocharset=utf8,sec=ntlm 0 0
//192.168.1.116/maps /mnt/share/mainpc/maps cifs
credentials=/home/patrick/.smbcredentials,iocharset=utf8,sec=ntlm 0 0

so mediapc is acting as a Samba server running 16.04 and this one mounts
just fine, mainpc is acting as a Samba server running 17.10 and it
always fails with error 13 permission denied.

Both servers have exactly the same credentials needed so they use the
same credentials file to provide those credentials to mount.cifs through
the mount command. So it fails regardless of whether I let it do it at
startup or if I type sudo mount -a to mount at any time of my choosing.

I have yet to try out any of the other things we have tried with this
computer so that will be my next step and based on so far it will
probably succeed.

On 13/07/17 04:53, Andreas Hasenack wrote:
> 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.
>

description: updated
Revision history for this message
Stefan Metzmacher (metze) wrote :

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.

Revision history for this message
Patrick Dunford (kahukowhai) wrote :

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 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.
>

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Can you try Stefan's suggestion from comment #17 please?

Revision history for this message
Patrick Dunford (kahukowhai) wrote :

I have already confirmed this in testing.

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

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, the default was changed to sec=ntlmssp."

So if you just remove it, it will use ntlmssp already. Kernel 3.8 was shipped in Ubuntu sometime between precise (3.2) and trusty (3.13).

Thanks for your comments, @metze

Revision history for this message
Patrick Dunford (kahukowhai) wrote :

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.

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

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.

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
Revision history for this message
punknroll (punknroll) wrote :

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

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.