Problem mounting network share

L

lorddevereux

New Member
Hello, I seem to be having a problem in trying to mount my new NAS drive (a D-Lik DNS-320L) on my Humax HDR-Fox-T2. For reference, the NAS drive is at 192.168.1.65 static, and the box at 192.168.1.74 static.

I've tried the network-shares-automount package as well as mounting myself. This package produces a command line of
mount -t cifs //192.168.1.65/Volume_1 /media/JurassicNAS -o user=XXXXX,password=XXXXX,domain=MYDOMAIN,unc=\\192.168.1.65\Volume_1
which fails:
mount: mounting //192.168.1.65/Volume/1 on /media/JurassicNAS failed: Invalid argument

If I try varying forms of the mount command using telnet I get either that error or "no such device or address"

Any ideas on how I could get more detailed error information? Thanks in advance!
 
Have you installed the cifs package as well? I can't remember if it gets installed automatically along with the automount package.
 
Cheers, but I've just checked and in webif "cifs" is listed as installed.

I have checked, and I can ping 192.168.1.65 no problem from the Humax. If I run smbclient -L 192.168.1.65 it correctly lists the shares available (of which one is Volume_1)

I tried mounting the NAS drive using my (Debian-based raspberry pi) Kodi media center and that worked fine using
sudo mount -t cifs //192.168.1.65/Volume_1 /media/NAS -o username=XXXX,password=XXXX

Whilst playing around on the pi, I got more detailed errors (like mount error(13): Permission denied). Is there some way I can get this information on the Humax?
 
lorddevereux said:
mount -t cifs //192.168.1.65/Volume_1 /media/JurassicNAS -o user=XXXXX,password=XXXXX,domain=MYDOMAIN,unc=\\192.168.1.65\Volume_1
which fails:
mount: mounting //192.168.1.65/Volume/1 on /media/JurassicNAS failed: Invalid argument
Click to expand...
There is logging information in 'scanmounts.log'. You may have to increase to debug level to get more information than in your above example (I'm not sure how to do this, but someone should be able to help).
I have highlighted a discrepancy above (in red). In the automount setup, an underscore is used to denote a dot (period) in the ip address. I would avoid the underscore in the name of the volume: it looks like the automount procedure is interpreting the underscore in 'Volume_1' as a directory marker and is trying to mount '/Volume/1' rather than '/Volume_1'.
 
MontysEvilTwin said:
You may have to increase to debug level to get more information than in your above example (I'm not sure how to do this, but someone should be able to help).
Click to expand...
I'm not sure the debug level will have any relevance in this specific case, but I believe you are referring to
WebIF >> Settings >> Auto-Processing Settings >> Auto-processing log level.
 
Thanks all! Yes, my bad - basically in setting it up in automount it mixed up the underscore and replaced it with a backslash. The share name is //192.168.1.65/Volume_1. All my testing since is being done via telnet commandline as I want to set up temporary shares only (for scripted copies) rather than a permanent one for access in the UI.

I CAN access the share using "smbclient //192.168.1.65/Volume_1 -U XXusernameXX" It asks me for the password and connects. I can then browse the share fine using ls, cd etc

I just cannot understand why it can connect that way, but can't mount?! I just get "No such device or address". I will try increasing the debug level in case.

EDIT: increased the debug level - saw nothing new in any of the log files :(
 
Last edited:
That's why you need to read the automount notes - it uses underscore as a proxy for slash (in paths, and as a proxy for dots in IP addresses - because these can't be used in the parameter passing mechanism used in network-shares-automount).
 
Last edited:
Black Hole said:
That's why you need to read the automount notes - it uses underscore as a proxy for slash (in paths, and as a proxy for dots in IP addresses - because these can't be used in the parameter passing mechanism used in network-shares-automount).
Click to expand...
Sorry maybe my post wasn't very clear, I appreciate that that bit is wrong, but for the moment I'm just trying to get it to mount at all! (let alone through automount). Unless automount does some other set up before running the main mount command?

I've found a rather hacky work-around for the moment, but it's far from ideal
smbclient //192.168.1.65/Volume_1 -l 192.168.1.65 -U USERNAME%PASSWORD -c "put \"HUMAX SOURCE PATH\" \"FULL PATH TO NEW FILE ON SHARE\""
 
I have a D-Link 320L too and had the same problems with it refusing to mount. I too tracked it down to the underscore in the share name "Volume_1".

I use the file editor in webif to manually change the code line starting "folder.. " in the scanmounts file to read:

folder=$(ls -1 "$name" | grep -e "^folder" | cut -d'=' -f2 | sed -e 's/_/_/g')

It works for me anyway.
 
mole_hill - looks like you have found a way to fix it. lorddevereux - the file in question is /mod/sbin/scanmounts.
If I am right though, the suggested modification to the scanmounts file will cause problems with any NFS shares that are set up since underscores are needed to define the mount points (with SMB shares the mount points are defined in a separate file).
 
mole_hill that seems to have worked! Thank you! Now I need to figure out why automount can run exactly the same command that I do in telnet, only it works and mine doesn't.
MontysEvilTwin I don't have any NFS shares so I should be alright, but I'll bear it in mind in future thanks.

automount runs: "mount -t cifs //192.168.1.65/Volume_1 /media/JNAS -o user=REMOVED,password=REMOVED,domain=REMOVED,unc=\\192.168.1.65\Volume_1" and mounts perfectly
I run EXACTLY the same in telnet CLI and get "invalid argument".

Does telnet run under a more restricted user, or do I perhaps need some more quotes in the line?
 
Everything runs as root.
You need to double your backslashes i.e. \\\\192.168.1.65\\Volume_1
as \ is the escape character.

Try this if you want to see for yourself:
echo \\192.168.1.65\Volume_1
echo \\\\192.168.1.65\\Volume_1
 
You must log in or register to reply here.
Back
Top