Description of problem:
Ktorrent offers the option of moving a downloaded set of torrent files to a new location once the download is completed. Although this function works fine on a local drive, it isn't working with SMB / CIFS.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Configure ktorrent to move completed torrent downloads to a specified folder.
2. Observe successful move when folder is on local device
3. Observe failure to move when folder is on an SMB/ CIFS share.
Failure to move files
Success in moving files
The failure seems to occur under both of these conditions:
1. when the address of the drive is added to the ktorrent configuration using a network address. example: smb://sharename/path/
2. When the SMB/CIFS share is mounted locally, so that the drive/folder should appear to be local.
This doesn't appear to be a permissions problem -- the same user running ktorrent on the local machine is the same user owning the destination path on the CIFS share. Additionally, the CIFS share is exported with promiscuous permissions (777) which allows any connected user has read/write/execute privileges. Dragging and dropping the files using Dolphin works just fine, it's just that Ktorrent isn't providing similar functionality.
Hej Bob, thanks for your bug report.
Can you please tell us which Samba version is running on the client/server? Also, can you please activate debug logging in Samba for the moment of the move and send us the debug?
On the CIFS client, where Ktorrent is running:
Samba version 4.1.9
PID Username Group Machine
Service pid machine Connected at
No locked files
On the CIFS server: protocols supported are up to and including SMB3.
max_open_files: increasing sysctl_max (11095) to minimum Windows limit (16384)
rlimit_max: increasing rlimit_max (11095) to minimum Windows limit (16384)
Samba version 4.1.9
PID Username Group Machine
Service pid machine Connected at
Registered MSG_REQ_DMALLOC_MARK and LOG_CHANGED
No locked files
1. Is that information adequate wrt samba versions?
2. which logs do you want to see debug mode? the server creates lots of logs under different names:
# ll /var/log/samba4
drwxr-xr-x 2 root wheel 8 Aug 3 12:14 ./
drwxr-xr-x 4 root wheel 45 Aug 3 12:00 ../
-rw-r--r-- 1 root wheel 12718050 Aug 3 12:14 log.nmbd
-rw-r--r-- 1 root wheel 47665304 Aug 3 12:21 log.smbd
-rw-r--r-- 1 root wheel 336595 Aug 3 12:13 log.wb-BUILTIN
-rw-r--r-- 1 root wheel 1689424 Aug 3 12:13 log.wb-NAS
-rw-r--r-- 1 root wheel 555514 Aug 3 12:13 log.winbindd
-rw-r--r-- 1 root wheel 212590 Aug 3 12:13 log.winbindd-idmap
I think we're barking up the wrong tree in assuming that this is a CIFS-related problem. After a bit more exploring, it seems that Ktorrent is not even attempting to write to the proper directory.
For example, I configured ktorrent to use ~/Downloads/torrents as the working directory, and to move the downloaded files to ~/Downloads/torrents-completed upon successful completion of the download. I then populated a queue of torrents to download, and let ktorrent perform the downloads. Ktorrent successfully moved the files from the local "torrents" folder to the local "torrents-completed" folder, as expected.
As the next step in the test I then used Ktorrent's configuration menu to create a new destination folder for the completed torrents on an SMB share; I created the new path on the destination CIFS share from within the ktorrent configuration menu, which confirmed ktorrent's ability to read/write to the new SMB share. This effectively put to rest any concerns that CIFS is causing a problem.
To verify this, I then downloaded some more torrents, and examined some smb logs in debug mode. Upon completing a download, Ktorrent didn't even attempt to move the files to the proper directory on the SMB share, and the logs showed no activity at all. Ktorrent instead moved the files to the "torrents-completed" folder on the host machine, a path that doesn't even exist anymore in the ktorrent configuration file.
It would seem that the problem is not with SMB/CIFS. It would appear that Ktorrent isn't even attempting to write to the proper path. Instead of using the current/existing path in the ktorrent configuration, ktorrent is using the path that previously existed in the ktorrent configuration, but isn't there any more. This errant behavior is survived by an exit/restart of ktorrent.
This behavior would be consistent with permanently associating the "move-to" upon completion path with the torrent at the time that the torrent is placed in the queue, and never re-updating this path information when the config file is changed after the torrent has already been queued. Essentially, this suggets that you can't reconfigure file paths in ktorrent once downloads have been queued, as the software ignores the path updates. That would be a design flaw.
Furthermore, if I change the final destination path to an SMB share, and then download a new torrent and place it int he download queue, ktorrent will begin the download into the ~/Downloads/torrents folder, and upon completion, the file should be moved to the SMB share path that was created within the ktorrent config menu. But instead of moving the file to the proper path, the file just disappears.
This suggetsts that ktorrent is A) associating the final destination path with the torrent at the time that it is queued, and ignores any further updates to the move-to path after the movement to the queue; B) ktorrent's move-to code fails to recognize SMB shares that were created by the ktorrent config menu, and deletes the files when it tries to move them.
I don't think this is a SMB/CIFS problem -- I think it's an internal problem in ktorrent.
Thanks for the detailed analysis - I filed an upstream bug, let's see what they say.
Thanks for your prompt reply, especially since it took me so long to get back with the test results.
I've googled for this problem, and it seems that my conclusions in (A) in the previous post were correct. Ktorrent's intended design is to associate the move-to path for completed downloads with the torrents at the time the torrents become queued. One might reasonably expect that changing the paths in the global system configuation would implement a global update to the file paths, but it doesn't. File paths are associated at the time of queing, and changes to the global file path after queueing do not effect what is already in the queue. What is already in the queue can have it's destination path updated by right-clicking on the torrent and editing the path. All things considered, I guess that (A) is a design feature, and not a bug.
(B) does look like a bug though. I created the destination path on the Samba share using ktorrent's configuration menus, so permissions should not be a problem. When the torrent has completed the download process and it's time to move, ktorrent deletes the file from the working directory without copying it to the SMB share. Evidently, ktorrent has a bug in it where: 1) it fails to write to the SMB share that it created earlier, and 2) it deletes the file from the source destination without bothering to conform that the write to the destination was successful! That's definitely a bug.
Thanks again for your help.
sorry, there's a typo above. that last part should read as follows:
2) it deletes the file from the source path without first bothering to confirm that the write to the destination path was successful! That's definitely a bug.
Hej bob, thanks for the more detailed analysis. Let's wait what the KDE guys say, maybe they can already point out what the problem is or show a way how to fix that...
It's been almost 3 months since the bug was opened. Any news from upstream?
has no activity or news, unfortunately
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 20 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.