[SOLVED] Trouble mounting network drive on Wandboard/Arch
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hi. I've installed Arch Linux on a Wandboard running Logitech Media Server (LMS). LMS needs to read my music files off of a NAS network share. I can't figure out how to mount that network share.
I was told by someone who has a similar NAS to make the following entry in etc/fstab:
But when I start LMS and point it to /mnt/netdrive, my media/Music folder isn't shown. Is there a problem with the way I'm trying to mount the network share?
I've tried using "root" and "admin" as username and the admin password of the NAS as password, but still no luck. I've tried mounting the share manually, but I get a "permission denied" error.
Have you checked the permissions of the share on the NAS?
You can check /var/log/messages or grep a dmesg for the NAS ip to get some information on what's happening during the connection attempt.
If it's properly configured, the connection should not require the administrative or root account passwords to be hard coded into the /etc/fstab, the original idea, having it mount as "nobody" or accomplish the authentication through a more restrictive pk/pki exchange (if security is a consideration) is correct.
Have you checked the permissions of the share on the NAS?
You can check /var/log/messages or grep a dmesg for the NAS ip to get some information on what's happening during the connection attempt.
If it's properly configured, the connection should not require the administrative or root account passwords to be hard coded into the /etc/fstab, the original idea, having it mount as "nobody" or accomplish the authentication through a more restrictive pk/pki exchange (if security is a consideration) is correct.
Thanks for your answer. I was able to solve the problem. I'll just quote you my post to the LSM forum:
<<I had given up and was about to go to bed when somebody on a French Arch forum answered my request for help, sending me to this page:
"Mount the share using the mount.cifs type. Not all the options listed below are needed or desirable (ie. password).
# mount -t cifs //SERVER/sharename /mnt/mountpoint -o user=username,password=password,workgroup=workgrou p,ip=serverip
Note: If you get the output "mount error(13): Permission denied", this might be due to a bug in mount.cifs. See the following bug report. https://bugs.archlinux.org/task/43015#comment130771 Try specifying the option "sec=ntlmv2" to work around it."
Outstanding, if you could mark the thread as "RESOLVED" in thread tools, that will help the next person searching the forums for a solution to the same problem.
Outstanding, if you could mark the thread as "RESOLVED" in thread tools, that will help the next person searching the forums for a solution to the same problem.
It's a windows based protocol that allows servers to authenticate their client machines, it makes it more difficult for one user to impersonate another in a situation where encryption based on passwords or public/private keys is not being used. In your case, it's how the NAS is confirming the identify of your wandboard
Last edited by dijetlo; 03-26-2015 at 03:59 AM.
Reason: Accuracy and of course spelling.
It's a windows based protocol that allows servers to authenticate their client machines, it makes it more difficult for one user to impersonate another in a situation where passwords or public/private keys are not being exchanged. In your case, it's how the NAS is confirming the identify of your wandboard
Thanks. In fact the NAS runs under Linux, and it's possible for me to enable the NFS protocol on it, even though CIFS is what's enabled by default. Since both the Wandboard and the NAS are under Linux, might I get better performance if I enable NFS and mount the share on the NAS with NFS? Of course, the share needs to be accessible (rw) to Windows computers too. At least that would get around this problem. My finding a solution was sheer luck...
You would get better performance with NFS (or at least you should) however, are you having performance issues?
Your solution wasn't sheer luck, it was the decision you made that you were going to work at the problem until you solved it. Once you made that commitment, it was only a question of time.
Your solution wasn't sheer luck, it was the decision you made that you were going to work at the problem until you solved it. Once you made that commitment, it was only a question of time.
Well, maybe, but when I say it was luck it's because I don't have the feeling I understand what I'm doing, of being able to eliminate possible causes and zero in on a few, and then on one. I'm groping around in the dark. Well, at least I know more than I did a few days ago...
Quote:
Originally Posted by dijetlo
You would get better performance with NFS (or at least you should) however, are you having performance issues?
Logitech Media Server is slow reading files over a network, and needs all the help it can get. I'm willing to try setting the share up as NFS if it's not likely to cause a lot of problems with Windows and if I don't have to destroy the share to set it up as NFS. The NAS front end has an option to enable NFS. If I enable it, can I set the share as both CIFS and NFS? Or do I have to disable CIFS? I see references to a Windows 7 service that can handle NFS. Any opinion on that?
The biggest issues I have with NFS surround it's unfortunate tendency to wander around on your ports, and the resulting mayhem that creates with firewall rules. There's a hack to fix that though.
Other than that, you have to turn on some RPC services, lockd, statd, quotd, a few others and configure the service on both the client and server. There's a lot of good documentation on it, just google Arch (you're using arch, right?) NFS and if you get stuck give me a shout.
Better yet, since we closed this thread, if you want to open another on that topic and put the link in this one, I'll follow it over and subscribe to that one as well.
To keep a site like this organized so it's usable as a resource for others, it's best to follow the posting rules. They're not trying to stifle discussion, far from it, but if you don't categorize what we're talking about it doesn't do anyone else any good. It also might dissuade someone more knowledgable than I from joining the discussion, since they think it's already over.
No worries about the help, I enjoy this stuff and I sense a like minded approach from you.
The biggest issues I have with NFS surround it's unfortunate tendency to wander around on your ports, and the resulting mayhem that creates with firewall rules. There's a hack to fix that though.
Other than that, you have to turn on some RPC services, lockd, statd, quotd, a few others and configure the service on both the client and server. There's a lot of good documentation on it, just google Arch (you're using arch, right?) NFS and if you get stuck give me a shout.
Better yet, since we closed this thread, if you want to open another on that topic and put the link in this one, I'll follow it over and subscribe to that one as well.
To keep a site like this organized so it's usable as a resource for others, it's best to follow the posting rules. They're not trying to stifle discussion, far from it, but if you don't categorize what we're talking about it doesn't do anyone else any good. It also might dissuade someone more knowledgable than I from joining the discussion, since they think it's already over.
No worries about the help, I enjoy this stuff and I sense a like minded approach from you.
Hi. I'm now trying to mount the same share using NFS after enabling NFS on my ReadyNAS, and can't manage to get it to work. I'm getting help from the folks at the Logitech Media Server forum, but it's tough going and anything you can do to help would be appreciated. If you want me to start a new thread here, just say the word - also if there's any info you need.
Thanks for your help in the past and, I hope, in the present!
Happy to oblige, Lestrad. Since we're talking about NFS and I think you've got the wandboard issues nailed down, why don't you start another thread. Put whatever data you have on the issue in the new post and just treat it like a separate issue. I'll keep an eye out for it but part of the service this website provides to the Linux community is the opportunity for people to develop their troubleshooting skills working with other user and I don't want to shortcut that process for others. It will also make the thread more valuable since people looking for solutions involving wandboards will find what they need in this thread already. People with NFS issues will find a separate thread more specific to their needs
Shhh... let the community puzzle over it a bit (24 hours), it's good for them, good for you.
I've got you subscribed and I think I can probably help,
No worries, amigo.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.