Bug 2131723 - Nautilus refuses to copy a complete directory to a Samba share...
Summary: Nautilus refuses to copy a complete directory to a Samba share...
Status: CLOSED DUPLICATE of bug 2127301
Alias: None
Product: Fedora
Classification: Fedora
Component: nautilus
Version: 37
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Matthias Clasen
QA Contact: Fedora Extras Quality Assurance
Whiteboard: RejectedBlocker
Depends On:
Blocks: F37FinalFreezeException
TreeView+ depends on / blocked
Reported: 2022-10-03 13:26 UTC by antonraves
Modified: 2022-10-21 19:10 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2022-10-21 19:10:39 UTC
Type: Bug

Attachments (Terms of Use)

Description antonraves 2022-10-03 13:26:53 UTC
Description of problem:

Nautilus refuses to copy a complete directory to a Samba share...

Version-Release number of selected component (if applicable):

How reproducible:

Copy a local directory to a Samba share using Fedora Linux beta 37 and Nautilus will not even begin copying, it will report "Error while copying "directory name" with sub error "There was an error copying the file into smb://ip.address/share_name" and "Permission denied".

The exact same action from another machine running Fedora Linux 36 stable performs like a charm. AT the Samba server end nothing has changed in between the installation of the Fedora Linux 37 beta machine and the other machine.

Looking with the Terminal at the main share it is odd to see all files and directories to have 700 as their permissions, where should be the regular 755 / 644...

A new directory can be made without worries, copying seperate files works also, just not a complete directory...

Steps to Reproduce:

Actual results:

"Permission denied"

Expected results:

A copy operation to take place

Additional info:

Comment 1 antonraves 2022-10-06 15:53:58 UTC
The Samba definition for this Nautilus problem:

  path = /srv/samba/share_name
  valid users = fedora_user
  browsable = yes
  guest ok = no
  writable = yes
  hide dot files = yes
  hide files = /~$*/~*/
  veto files = /._*/.DS_Store/
  delete veto files = yes
  create mask = 0644
  directory mask = 0755
  veto oplock files = /*.doc/*.docx/*.xls/*.xlsx/

Comment 2 Fedora Blocker Bugs Application 2022-10-19 14:55:13 UTC
Proposed as a Blocker for 37-final by Fedora user bcotton using the blocker tracking app because:

 Arguably violates the Final criterion: 

For all release-blocking desktop / arch combinations, the following applications must start successfully and withstand a basic functionality test: file manager

Comment 3 Kamil Páral 2022-10-19 15:26:12 UTC
I can reproduce this problem in my home with nautilus-43.0-2.fc37.x86_64 and a SMB share provided by my router.

Comment 4 Stephen Gallagher 2022-10-19 16:56:58 UTC
Does copying a complete directory work from the command line? Can you run `cp -a /path/to/dir /path/to/smb/share` successfully?

Comment 5 antonraves 2022-10-19 17:04:15 UTC
@sgallagh I tried as you asked and both with and without a "sudo" I got the error message "cp: cannot stat '/run/user/1000/gvfs/smb-share:server=,share=share_name/ test_directory': Permission denied", this of course with the IP address of the Samba server, not redhat.com.

Comment 6 Adam Williamson 2022-10-19 17:45:01 UTC
well, this is likely really a gvfs issue, i.e. it's to do with how gvfs mounts the share when you discover a network location in Nautilus.

With a manually configured smb share this works fine for me, I just tested. I can copy a folder to a manually mounted SMB share in nautilus no problem.

Comment 7 Gary Buhrmaster 2022-10-19 23:35:20 UTC
This may (or may not) be related to https://bugzilla.redhat.com/show_bug.cgi?id=2127301 (fix available as of a few hours ago) and https://gitlab.gnome.org/GNOME/gvfs/-/issues/651 which suggests a samba issue.  It might be worth seeing of the samba update resolves the issue.

Comment 8 Ondrej Holy 2022-10-20 10:37:12 UTC
Yes, this is most probably related to Bug 2127301. Or are you able to reproduce this with samba-4.17.1-1.fc37 (https://bodhi.fedoraproject.org/updates/FEDORA-2022-1b0ba70aca)? If so, please provide debug log using the steps from https://wiki.gnome.org/Projects/gvfs/debugging#Getting_debug_logs with GVFS_SMB_DEBUG=10 envar set in the second step...

Comment 9 antonraves 2022-10-20 17:28:17 UTC
With samba-4.17.1-1.fc37 installed a complete folder / directory can be copied to the Samba-share without any worries! Then it works!

Comment 10 Kamil Páral 2022-10-21 07:10:13 UTC
I can also confirm samba-4.17.1-1.fc37 fixed the issue for me.

Comment 11 Kamil Páral 2022-10-21 07:14:19 UTC
Rejected as an F37 blocker in https://pagure.io/fedora-qa/blocker-review/issue/979 .

Comment 12 Adam Williamson 2022-10-21 16:40:45 UTC
Since we've skipped, we have scope to pull this in as an FE, so proposing it.

Comment 13 Adam Williamson 2022-10-21 19:10:39 UTC
I think we can just make this a dupe of 2127301, right?

*** This bug has been marked as a duplicate of bug 2127301 ***

Note You need to log in before you can comment on or make changes to this bug.