2

A server "S" runs Ubuntu 18.04 LTS and Samba 4.7.6-Ubuntu. smb.conf has been left with all the default settings, except for workgroup name changed, and the following blocks added at the bottom:

[lan_share]
   path = /disk2
   browseable = yes
   read only = yes

[lan_share_1]
  path = /disk1
  browseable = yes
  read only = yes

[lan_share_3]
  path = /disk3
  browseable = yes
  read only = yes

When the client was Debian 8 with packages samba and 'cifs-utils`, everything worked as expected, including ability to copy from the client-mounted share to local disks.

Now new client, workstation "W", is running Ubuntu 18.04 LTS with the latest samba and cifs-utils, and copying from shares to local is not working.

The shares on W are set up by lines in /etc/fstab as follows:

//192.168.1.233/lan_share_1 /disk1     cifs  credentials=/etc/samba/user,noexec  0 0
//192.168.1.233/lan_share   /disk2     cifs  credentials=/etc/samba/user,noexec  0 0
//192.168.1.233/lan_share_3 /disk3     cifs  credentials=/etc/samba/user,noexec  0 0

There's a credentials file at the path listed above which, again, works fine with Debian, and probably is OK on Ubuntu too, as there are no error messages about permissions.

All this has been copied exactly from the Debian client which had no problem. Now an attempt to copy a directory tree thru the GUI file browser - say, from /disk2 to home directory - will appear to succeed at first, then the progress dialog freezes partway thru and can't even be cancelled. The progress dialog remains until the Thunar (file browser) process is killed - unless the user clicks the big red "Cancel" icon, in that case the dialog says "Cancelling..." until the process is killed. Only the first few files get copied.

I've checked that:

  • workgroup name is the same on both server and client
  • ufw on the server allows the ports in "samba" application profile
  • files in the share are OK on the server (accessible via SSH, SCP)
  • everything else works correctly on the client

I still have the Debian system where everything works normally when connecting to the same share - a whole directory structure can be copied from the share to local thru the GUI. Web searching has found various other Samba issues, some relating to going from earlier versions to Ubuntu 18, but none quite describing this situation.

Update: This ("Trouble mounting cifs shares after upgrade to 17.10") looked promising. I found out the "noexec" is unnecessary (1) and based on the former page, I replaced the ",noexec" with ",vers=2.1".

Also, on the server, did this: sudo chmod-R 775 /disk2. And with one or both of these changes in place, I can now successfully copy from the locally mounted share to home directory using command line - but it still makes Thunar hang. Now thinking it may be at least partially a GUI problem.

Update: Thanks Terrance, I'm going to check out NFS right away. I don't have Windows clients and if it's less problematic, well I just need the functionality.

  • +1 for a great question. Unfortunately, I have not stumbled across your issue with my network, but there were some issues I did have with cifs. Mostly cosmetics like incorrect used space reporting from server side. askubuntu.com/questions/1058815/… I ended up going with NFS on the server side but kept Samba as well. The speed on the NFS is faster and I get the correct used space reporting. – Terrance Nov 8 '18 at 15:13
1

I had the same problem with Linux mint xfce 19.1 and 19.0. First I had a problem with my “WD My Book Live” NAS server. I solved this with adding vers=2.0 in fstab (I tried vers 3.0 2.1 and 2.0 and chose the highest working version). First I thought the problems were solved, but later there were sometimes problems with copying files from the NAS. The problem only appears while copying files with extension html ,gif,ico and txt (but makes a good copy of the problem files). After making a copy of these files, the copy process freezes. Copying files with extension flac, zip and tar.gz was no problem. When copying multiple files, the copy process freezes when it reaches the problem files. I solved it by changing vers=2.0 to vers=1.0 in fstab. There seems to be a compatibility problem with version 2.0? With testing the NAS connection, I used a 3 Gb iso file. I don’t copy much of those problem files (may be there are more problem extensions) from my NAS, so the problems mostly keeps invisible. But after some times I understand there was a structural problem with some extensions. And maybe the extensions are not the problem, but may be the sizes of the files are the problem. With my example files the problem files were small!

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.