Bug 308095 - Cannot work from NFS mounted directory.
Summary: Cannot work from NFS mounted directory.
Status: RESOLVED DUPLICATE of bug 306825
Alias: None
Product: ktorrent
Classification: Applications
Component: general (show other bugs)
Version: 4.3.0
Platform: Fedora RPMs Linux
: NOR major
Target Milestone: ---
Assignee: Joris Guisson
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-08 21:32 UTC by Emmett Culley
Modified: 2012-10-18 18:57 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Emmett Culley 2012-10-08 21:32:31 UTC
I am seeing error dialog when download directory is an NFS mount.  The dialog message is: "One or more storage volumes are not mounted. In order to start this torrent, they need to be mounted."  The dialog lists the mounted directory, (i.e., /fs1/work) while the configured directory is /fs1/work/BitTorrent.

I tried starting a new torrent using a local partition (my home directory) and there was no problem.

One note: If I right click on a torrent that is assigned to the NFS mount (it is red) and select Advanced | Open directory | Data directory I see the contents to the destination directory on the NFS mount.

I set permission to world read/write.  No difference.

Reproducible: Always

Steps to Reproduce:
1.  Mount NFS share (NFS3 or NFS4)
2.  Open KTorrent
3. All torrents assigned to that mount point fail to activate and a popup error dialog is presented for each torrent in the list that is assigned to that mount point.
Actual Results:  
Cannot download torrents to file server, only to local drives.

Expected Results:  
As in the past, be able to download torrents to file server.

This is pretty new, but I am not sure of the exact version this started, though there couldn't have been more that two or three updates since it worked correctly.  I am running an fully updated Fedora 17 system.  That's KDE 4.9.2.
Comment 1 Joris Guisson 2012-10-13 09:07:23 UTC
How do you mount those NFS shares ?
Comment 2 Emmett Culley 2012-10-13 16:05:39 UTC
They are mounted via fstab:

fs1:/work     /fs1/work   nfs   rw,noatime 0 0
#fs1:/nfs/work      /fs1/work   nfs   nfsvers=3,rw,noatime 0 0

I tried both nfs3 and nfs4.  Neither mount could be accessed by ktorrent.
Comment 3 Joris Guisson 2012-10-15 18:38:29 UTC
Starting torrents on NFS works without problems here  (it's a local NFS but that shouldn't matter, it's an nfs shared mounted via /etc/fstab)

Do you have the proper permissions to write there ? If ktorrent can determine that the files are on NFS at torrent load time, it should be able to see that the NFS is mounted, this doesn't make any sense.
Comment 4 Emmett Culley 2012-10-16 02:39:58 UTC
I suppose "doesn't make sense" is the reason I reported the bug :-)  

Whenever I start ktorrent I get five popup dialogs with the message noted above.  One for each torrent that is still active.  If I then right click on an item (in red) and select "check data", the check data process works as expected, and has no problem reading the files accessed by the NFS share.

However, if I select "move data", I am allowed to move about in that tree and on other NFS mount points via the file dailog presented, but when I select any new location then click on OK, I get the same error dailog as described above.  That is it won'r allow me to access the location of the torrent I selected to move.

As for permissions, my user has no problem reading or writing to any file in that mount.  To make sure, I made the entire tree world r/w/x.  That made no difference.

I've tried getting a new torrent and it does the same thing when I tell ktorrent to put it in the directory supplied by that share.
Comment 5 Joris Guisson 2012-10-18 18:57:35 UTC
In 4.3.0, KDE's solid library is used to find all mounted partitions, but that had problems with btrfs, so I have added another method for linux to deal with this problem (which uses /proc/mounts). This should also fix this problem.

Fix will be part of 4.3.1

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