SUMMARY We have been using Krusader for a few years to synchronise files between three dual-boot Ubuntu / Windows machines and it has worked well. We've recently upgraded to Ubuntu 20.04, and while testing things out we discovered that in 20.04 Krusader was no longer able to properly synchronise directories shared with Samba. Until upgrading to 20.04, we simply opened Nautilus and connected to the share over the network by finding the server listed in "Other locations" in Nautilus. When clicking on the required server name a list of shared locations was shown on this server and we then selected the location we wanted to mount to sync up. We then used Krusader to navigate to the share mounted with gvfs eg: /run/user/1000/gvfs/share-name and then used Krusader to sync up the two directories. When syncing up the original modification dates of files were preserved on files that were copied across. Now if we click on a server listed in "Other locations" in Nautilus an error window is displayed with the message: Unable to access location, Failed to retrieve share list from server: Invalid Argument. This may be because of the removal of SMB1 / NT1, so we had to find a new method of mounting the share. We do not want to set the samba servers to use SMB1 as this is now regarded as insecure. We found a new method but unfortunately this does not work with Krusader. It does work with Double Commander. The new method we found was as follows: 1) In Nautilus 'Other Locations' we type in the samba server address including the shared location eg: smb://192.168.1.99/Storage This brings up the window prompting for user name and password for the samba share. After this the samba share location can be accessed through Nautilus as normal and the modification dates of files that are copied using Nautilus are preserved. 2) We then use Double Commander to navigate to the share at /run/user/1000/gvfs/share-name and sync up the two directories with this. Modification dates of files that are copied are preserved. Krusader is our preferred application. We tried using Krusader in the same way, and it was only partly successful: STEPS TO REPRODUCE 1. In Nautilus 'Other Locations' we type in the samba server address including the shared location eg: smb://192.168.1.99/Storage This brings up the window prompting for user name and password for the samba share. After this the samba share location can be accessed through Nautilus as normal and the modification dates of files that are copied using Nautilus are preserved. 2. We then use Krusader to navigate to the share at /run/user/1000/gvfs/share-name and sync up the two directories with this. OBSERVED RESULT The synch with Krusader partly works OK, but larger files over about 4MB time out before they have finished copying whereas Double Commander works without any problem. The modification dates of the files that are copy successfully are preserved. EXPECTED RESULT All files selected for copying should copy successfully and the modification dates should be preserved. SOFTWARE/OS VERSIONS Linux/Ubuntu 20.04 ADDITIONAL INFORMATION
Is the same issue also visible with Dolphin? It could be an issue with a component that is used by Krusader, instead of in Krusader itself.
Hi Christoph, thanks for the reply. We don't currently have Dolphin installed, but we will put it on and give it a try to see what happens. It may well be a supporting component that's implicated, but I did check that we had KIO Extras installed and at the latest version. No-one else seems to have reported this exact problem, so maybe that suggests there is an issue on one of our machines. I will get back to you.
(In reply to Christoph Feck from comment #1) > Is the same issue also visible with Dolphin? It could be an issue with a > component that is used by Krusader, instead of in Krusader itself. Hi Christoph, we have tried again using Dolphin, and the same error occurs. When trying to manually copy a larger file (e.g. 19 MB, 64 MB) it starts copying but stops part way through with following error message:- Cannot copy file from /local/a.jpg to /remote/a.jpg (Errno:95) It gives option to retry the copy but the same thing happens. I have found one report of an identical issue with Dolphin from 11 months ago: https://www.reddit.com/r/kde/comments/cq45rp/gvfs_mounts_with_dolphin_error_95/ The person who raised this thought it might be due to to something deciding that there was not enough space on the receiving partition to do the copy, but no-one answered his post so it doesn't help much (except to confirm that someone else has seen this).
Moving bug to KIO. kio-extras don't play into this since the share is accessed through gvfs (i.e. that's file->file from a KIO point of view).