Autotools plugin cannot see fstab mounted network share

[GoogleCodeExporter]

What steps will reproduce the problem?
1.mount smb entry with cifs via /etc/fstab on xubuntu 13.10 to a folder in 
default admin user /home/ (authenticated or guest
2.launch rutorrent and attempt to browse or manually type in location on 
mounted folder with autotools plugin
3. attempt to fix with full permissions for all users (ie chmod -R 777 
/home/user/)
4. attempt to fix with linked folder (ie ln -s /mnt/share /home/user/share)

expected output - able to utilize mounted folder either via manually typed path 
or by browsing to mounted path

actual output - manually typing path causes no watches/moves/labels to take 
place | attempting to browse to the mounted share to results in the mount not 
showing up

What environment are you using?
1. My ruTorrent version is... v3.6 (svn $Rev:2404 $)
2. My rTorrent version is... 0.9.3
3. I use web-server... it version is... on OS...  Apache/2.4.6 (Ubuntu) on 
XUbuntu 13.10
4. I use browser... it version is... on OS... Google Chrome Version 
31.0.1650.57 m on Windows 8

Are some errors present in the web-server log?

Are some errors present in the browser error console?

Please provide any additional information below.

If error logs are needed please advise where I can look for them so I can post. 
Please note I have searched for solutions to this issue and have found that my 
instance is not isolated, any forum posts I have created on the topic have gone 
unanswered to date.

Original issue reported on code.google.com by smashthi...@gmail.com on 3 Dec 2013 at 9:24

[GoogleCodeExporter]

1) Check $topDirectory variable.
2) Turn selinux off.

>If error logs are needed please advise where I can look for them so I can post

I'm not a telepathist. This is a *your* system. *You* must know, where *your* 
webserver store it's errors logs.

Original comment by novik65 on 4 Dec 2013 at 4:54

[GoogleCodeExporter]

You are right of course, my apologies. Error logs for apache2 showed no issues 
with the exception of unset time zone in php.ini, which I fixed just in case, 
but was not relevant.

$topDirectory is currently set to /

Setting $topDirectory works as expected if set to anything else, and works for 
/ as well. 

selinux is currently disabled.

checking error console for google chrome shows nothing when attempting to 
browse, and shows a somewhat expected error when attempting to browse after 
having entered the path manually:

Uncaught TypeError: Cannot set property 'className' of null 
getdirs.php?dir=%2Fmnt%2Feffinnas&btn=automove_browse_btn&edit=path_to_finished&
frame=automove_brow…:36
menuClick 
getdirs.php?dir=%2Fmnt%2Feffinnas&btn=automove_browse_btn&edit=path_to_finished&
frame=automove_brow…:36
init 
getdirs.php?dir=%2Fmnt%2Feffinnas&btn=automove_browse_btn&edit=path_to_finished&
frame=automove_brow…:23
onload 
getdirs.php?dir=%2Fmnt%2Feffinnas&btn=automove_browse_btn&edit=path_to_finished&
frame=automove_brow…:74

Original comment by smashthi...@gmail.com on 4 Dec 2013 at 6:39

[GoogleCodeExporter]

upon further testing, this issue is not isolated to the autotools plugin, and 
rather seems to be _getdir as it takes place throughout rutorrent.

I have confirmed at this point that php can read the mounted folder with the 
below code

<?php
$dir    = '/mnt/effinnas';
$files1 = scandir($dir);
print_r($files1);
?>

I have also confirmed that rtorrent can write to the default download directory 
after adding a torrent to rutorrent via browser.

Original comment by smashthi...@gmail.com on 4 Dec 2013 at 7:41

[GoogleCodeExporter]

>Uncaught TypeError:

This is a result of empty list, not it's reason.

>I have also confirmed that rtorrent can write to the default download directory

rtorrent must have ability for read/write/execute (i.e. 07) to '/mnt/effinnas' 
directory. Default download directory hasn't relation to your case.

Original comment by novik65 on 5 Dec 2013 at 5:07

[GoogleCodeExporter]

That is my default directory, apologies again if that was unclear. 

rTorrent is able to read/write the /mnt/effinnas directory just fine as I've 
defined in rTorrent.rc 

the directory permissions to /mnt/effinnas are current set to 777 with the 
fstab entry

Original comment by smashthi...@gmail.com on 5 Dec 2013 at 5:14

[GoogleCodeExporter]

Can't reproduce this, sorry.
We have two cases:
1) You give to me SSH+ruTorrent account for you system, and i will look, what i 
can to do (i think, really this is a not a case ;))
2) You will try to found solution by yourself. For this you should check file
rtorrent/plugins/_getdir/getdirs.php, line 50. Add 'else' part to the 
corresponding 'if' operator and insert debug output in it.

Original comment by novik65 on 5 Dec 2013 at 8:32

[GoogleCodeExporter]

feel free to close the defect. I started from scratch with another distro, 
building the same way, issue is resolved. 

Original comment by smashthi...@gmail.com on 6 Dec 2013 at 9:23

[GoogleCodeExporter]

Original comment by novik65 on 7 Dec 2013 at 6:32

• Changed state: Invalid

[GoogleCodeExporter]

I came across this via google search as I was experiencing the same/similar 
issue. After a little bit of debugging I traced down the issue and solution for 
others with this problem. In my case I tracked the problem down to the fact the 
PHP function is_dir() was returning false on everything that was mounted to a 
cifs share, *including directories*, even when all files/folders are 777. 
Obviously this will cause all kinds of fun problems with rutorrent.

***Cause: at least in my case (via comment from php manual for is_dir() @ 
http://us1.php.net/manual/en/function.is-dir.php ) is on 2.6.31 and newer linux 
kernels they've started using the CIFS serverino option by default.  With 
Windows shares this causes huge inode numbers and which apparently can cause 
is_dir() to return false. Adding the "noserverino" option to the options 
provided when mounting the CIFS share will prevent this. Some distros/packages 
may change the default used for serverino with cifs shares so it's at least 
worth checking, especially if is_dir() is returning false on directories 
mounted in your cifs share (This also explains why when OP switched distros it 
started working).

***Solution: in this case basically you just need to make sure you add the 
"noserverino" in your list of options for mounting the cifs share.*** 

Extra info/sample: Sample entry from my /etc/fstab file for a cifs share in 
case anyone else with this problem may find this helpful. Note: you will 
probably have to change the path to the password file to wherever you store it, 
as yours is probably not at /root/smbcredentials
\\10.0.0.21\SeedboxDL   /mnt/SeedboxDL cifs 
noserverino,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777,credentials=/root
/smbcredentials 0 0

This will give you the share mounted to /mnt/SeedboxDL with 777 permissions for 
all files/folders. Just make sure your mount point already exists before trying 
to mount it and that it has the correct permissions before mounting, and don't 
forget to check that /mnt has the correct permissions as well.

Hopefully this helps someone else who encounters this issue :)

Original comment by nathanlo...@gmail.com on 2 Apr 2014 at 9:01