Can't copy from Samba shares after upgrade to 18.04
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.
server 18.04 samba
add a comment |
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.
server 18.04 samba
+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
add a comment |
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.
server 18.04 samba
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.
server 18.04 samba
server 18.04 samba
edited Nov 8 '18 at 19:48
stephen_789
asked Nov 8 '18 at 14:05
stephen_789stephen_789
1214
1214
+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
add a comment |
+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 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 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
add a comment |
1 Answer
1
active
oldest
votes
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!
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1091132%2fcant-copy-from-samba-shares-after-upgrade-to-18-04%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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!
add a comment |
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!
add a comment |
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!
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!
answered Jan 1 at 19:14
André KappertAndré Kappert
111
111
add a comment |
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1091132%2fcant-copy-from-samba-shares-after-upgrade-to-18-04%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
+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