How to mount a NFS share?

[the1weasel]

Hello there!

I'm not sure wether this is the right Forum thread, nor if it's even possible.
English is not my first language, but i hope i can make myself clear and explain my problem.

As in the title mentioned I just want to mount a nfs share into my filesystem so that i can access my media through a vpn whereever I go.

I'm using a Synology Diskstation as NAS and created some NFS-shares (tried version 3 and 4) which are accessable in my Network. It's working flawless with my raspberry pi and with my debian system. I don't want to use smb (cfis).
I want to use my favorit musicplayer to listen to my music, mounted via fstab in the musicfolder for example.

Right now i'm using the yatse app, works fine - but it's just a workaround....

I tried FreedomOS(stock kernel and elementalx)+busybox and Resurrection Remix(stockkernel and lightningkernel)+ busybox. All i get is Invalid argument or error messages. I just can't get it to work. It's a linux system, why can't i use a simple nfs share?

Any help would be apreciated.
Thanks in advance!

 

[maikvitesse]

I used to mount a nfs share with busybox so be sure to have that installed.

next be sure to have a working VPN connection to your home network.

One more thing to check is that VPN connections are allowed to access the nfs shares. Dont know if you need to set this up with synology or that it's enabled by default.

 

[the1weasel]

Thanks for the response.
I have all permissions set to get access to the nfs-share, tried it without vpn aswell. The vpn itself is working like a charm.
I have access to my NAS via webinterface and sftp, i can control and stream from my raspberry pi aswell. No problems with the vpn for sure.

I'm using busybox aswell. Can you post me your mount command or your fstab line for the mount?

 

[maikvitesse]

Thanks for the response.
I have all permissions set to get access to the nfs-share, tried it without vpn aswell. The vpn itself is working like a charm.
I have access to my NAS via webinterface and sftp, i can control and stream from my raspberry pi aswell. No problems with the vpn for sure.

I'm using busybox aswell. Can you post me your mount command or your fstab line for the mount?

I used this i believe.
Your kernel needs to support it.
https://gist.github.com/aldur/4a3f90a111b71662f056

 

[the1weasel]

I used this i believe.
Your kernel needs to support it.
https://gist.github.com/aldur/4a3f90a111b71662f056

Thats exactly what i was told over here https://forum.xda-developers.com/oneplus-5/development/kernel-elementalx-op3-1-00-t3626808/post73156290#post73156290

I will follow up on that, thanks for pointing me in the right direction aswell.

 

[the1weasel]

Ok, i was able to mount the share.

Now that it's getting a general question i will follow up here. I posted what i did over here aswell and got it solved to this state.

I can see the files in the Terminal, but not in any App (explorer, musicplayer etc.).

As i already wrote here: https://forum.xda-developers.com/showpost.php?p=73161675&postcount=437 I'm guessing it's because i mounted as root so normal users can't use it. Or at least thats what I'm thinking.

I searched the forum already and just found a thread with someone having the same problem without solution.

Is there a way that i can use the mounted share with any app I want?

 

[the1weasel]

Just for the roundup.

Here is whats working:
mount a nfs-share through an terminal app. => Files are visible/browsable

whats not working:
Use the mounted nfs-share systemwide with any other app.

What i tried (used Termux):
mount into /mnt/remotenfs => files show up in terminal, just there.
mount into /storage/emulated/0/Music/remote => files show up in terminal, just there.
mounted the share and then started an explorer (solidexplorer) from terminal - same result. No fileaccess through explorer.

 

[hachamacha]

Just for the roundup.

Here is whats working:
mount a nfs-share through an terminal app. => Files are visible/browsable

whats not working:
Use the mounted nfs-share systemwide with any other app.

What i tried (used Termux):
mount into /mnt/remotenfs => files show up in terminal, just there.
mount into /storage/emulated/0/Music/remote => files show up in terminal, just there.
mounted the share and then started an explorer (solidexplorer) from terminal - same result. No fileaccess through explorer.

I think I suggested something like this as a way to glean some information about this problem in the other thread, but don't recall for certain what the outcome if any was:

At least since V5 and above of Android OS, there's been some sort of thread insularity that keeps another thread from seeing what some of the first one sees. (moreso than before V5). I figured that since fstab.qcom (or whatever the name of the actual startup file where "mount -a" is pointed) must contain the mounted partitions that are visible to all. If that's the case, it's either the startup mount daemon, or it is in one of the columns of each "mount" entry in fstab.*.

I think I suggested adding a mount entry without the "automount at start" parameter for your remote music. Just curious if that was tried? Also, I thought the file where these were entries were kept in M & N (6 & 7) had "*vold*" in the title.

I'm also curious about this and will look around for some better answer because it seems very non-linux / android that only the thread performing the action can see the result (although that is how local actions / variables act).

After some poking around: I think this link explains some possible reasons for this behavior, not that there isn't some way around it. Probably there is no way around it without some compromise of whatever privacy additions android OS is after. It sounds a lot like an SELinux & /proc FS change. https://stackoverflow.com/questions/38590140/file-system-changes-in-android-nougat

 

[the1weasel]

I think I suggested something like this as a way to glean some information about this problem in the other thread, but don't recall for certain what the outcome if any was:

At least since V5 and above of Android OS, there's been some sort of thread insularity that keeps another thread from seeing what some of the first one sees. (moreso than before V5). I figured that since fstab.qcom (or whatever the name of the actual startup file where "mount -a" is pointed) must contain the mounted partitions that are visible to all. If that's the case, it's either the startup mount daemon, or it is in one of the columns of each "mount" entry in fstab.*.

I think I suggested adding a mount entry without the "automount at start" parameter for your remote music. Just curious if that was tried? Also, I thought the file where these were entries were kept in M & N (6 & 7) had "*vold*" in the title.

I'm also curious about this and will look around for some better answer because it seems very non-linux / android that only the thread performing the action can see the result (although that is how local actions / variables act).

After some poking around: I think this link explains some possible reasons for this behavior, not that there isn't some way around it. Probably there is no way around it without some compromise of whatever privacy additions android OS is after. It sounds a lot like an SELinux & /proc FS change. https://stackoverflow.com/questions/38590140/file-system-changes-in-android-nougat

Thanks for the response, looks like you are much more into that android thing....

I just added

"10.11.12.10:/volume1/Audio /storage/emulated/0/Music/remote nfs nolock,ro defaults"

to the fstab.qcom . Doesn't mount at startup.

I realized some inconsitency in the ssh thing, sometimes it works mounting via ssh, sometimes not....strange. (mount: applet not found)
To be sure i'm doing all that stuff without ssh.

Edit:
For everyone else reading this. It's not about music, the musicfolder is just a random folder to see if it's working.

 

[hachamacha]

Thanks for the response, looks like you are much more into that android thing....

I just added

"10.11.12.10:/volume1/Audio /storage/emulated/0/Music/remote nfs nolock,ro defaults"

to the fstab.qcom . Doesn't mount at startup.

I realized some inconsitency in the ssh thing, sometimes it works mounting via ssh, sometimes not....strange. (mount: applet not found)
To be sure i'm doing all that stuff without ssh.

Edit:
For everyone else reading this. It's not about music, the musicfolder is just a random folder to see if it's working.

To add to that: It doesn't seem like any surprise that just putting an entry in the fstab.qcom doesn't work the same as the others. As I search around for a way to do this it becomes apparent that even a Synology app designed to do this (DS File) (Mounts a NFS share on Synology box and allows file transfers) isn't able to allow others to see it's mounted share.

Before I mounted a Synology folder using Synology DS File, I created a tmp folder and cd there and then did a mount > mountbefore.log. After the mount of the share while still running DS File pointing to my Synology folder, I did a mount > ./mountafter.log. I then did a diff -urN (and just a diff) ./mountbefore.log ./mountafter.log that showed no differences. That seems telling.

Also, I did the same with /proc/mounts /proc/mountinfo /proc/mountstatus before and after, and nothing showed up as different. Also I did a ps | grep DS to see whether the ps output gave me any clue as to what local mount point was used, but though I could see the DS process, I couldn't see it's mountpoints.

I'm pretty sure there's an SELINUX (or many) entrie(s) for the mounted share that prevent the usual visibility. I recall reading that "fixing" the /proc exploits was a big priority with the advent of SElinux so I'll look at that angle too. I don't think that the fact that DLNA works is of much use in this problem. It's really a solution to a different and specific problem.

 

[the1weasel]

To add to that: It doesn't seem like any surprise that just putting an entry in the fstab.qcom doesn't work the same as the others. As I search around for a way to do this it becomes apparent that even a Synology app designed to do this (DS File) (Mounts a NFS share on Synology box and allows file transfers) isn't able to allow others to see it's mounted share.

Before I mounted a Synology folder using Synology DS File, I created a tmp folder and cd there and then did a mount > mountbefore.log. After the mount of the share while still running DS File pointing to my Synology folder, I did a mount > ./mountafter.log. I then did a diff -urN (and just a diff) ./mountbefore.log ./mountafter.log that showed no differences. That seems telling.

Also, I did the same with /proc/mounts /proc/mountinfo /proc/mountstatus before and after, and nothing showed up as different. Also I did a ps | grep DS to see whether the ps output gave me any clue as to what local mount point was used, but though I could see the DS process, I couldn't see it's mountpoints.

I'm pretty sure there's an SELINUX (or many) entrie(s) for the mounted share that prevent the usual visibility. I recall reading that "fixing" the /proc exploits was a big priority with the advent of SElinux so I'll look at that angle too. I don't think that the fact that DLNA works is of much use in this problem. It's really a solution to a different and specific problem.

Hmm I just found this: https://forum.xda-developers.com/showthread.php?t=2106480 and will have a closer look into it later, I'm running out of time right now and have to leave.
But what I've read so far looks similar to the problem we are facing right now. Maye thats the way to go. I'll try it, as I said, later.
At this point i don't even care if it's smb or nfs as long as i can mount my stuff into the filesystem.

 

[hachamacha]

One other thing I noticed but haven't messed around with yet is that I was looking at the various mount commands for different implementations (not that any will just work like 2 versions ago), and noticed that only /system/xbin/mount is a soft link to /system/xbin/busybox (standard busybox link to allow using it various look-alike-to-linux commands.

But then I realized that /system/bin/mount is also there, also a soft-link to /system/bin/toybox (another busybox clone) and am wondering if it behaves any differently. Might be worth a look (but I doubt it). /system/bin/toybox is at least a different version of busybox and not linked to it.

Just looked at your last reply and realized that unfortunately the two links of interest are at the now nonexistant domain cyanogenmod.org. Maybe the diffs are worthwhile. Gotta work, Later.

 

[the1weasel]

One other thing I noticed but haven't messed around with yet is that I was looking at the various mount commands for different implementations (not that any will just work like 2 versions ago), and noticed that only /system/xbin/mount is a soft link to /system/xbin/busybox (standard busybox link to allow using it various look-alike-to-linux commands.

But then I realized that /system/bin/mount is also there, also a soft-link to /system/bin/toybox (another busybox clone) and am wondering if it behaves any differently. Might be worth a look (but I doubt it). /system/bin/toybox is at least a different version of busybox and not linked to it.

Just looked at your last reply and realized that unfortunately the two links of interest are at the now nonexistant domain cyanogenmod.org. Maybe the diffs are worthwhile. Gotta work, Later.

I'm back home already a little late but enaugh time for more researches.
This link:

https://github.com/mkasick/android_...mmit/b358bf82c079a577f011c167da8b65faef73a06e

is working. And really worth reading it and explains the visibility problem.

 

[the1weasel]

Android 4.2 breaks Dalvik-apps that mount file systems to be shared with other apps. This includes CifsManager, Mount Manager, essentially anything that mounts cifs shares, FUSE file sytems, etc. The symptom is that the mounted contents appear fine to app that peforms the mount operation (assuming the app itself provides the ability to browse the contents), but every other app only sees an empty directory at the mount point.

It turns out that this problem is a side-effect of the approach used to implement multi-user storage in Android 4.2. I've explained the problem in detail in the commit log for a Gerrit issue we're reviewing for CyanogenMod 10.1 that addresses the problem:


Ideally, any 4.2 ROM can provide support for CifsManager by applying a change to Dalvik, and a second change to the boot ramdisk's init.rc:

• Dalvik change: Zygote: Restrict slave mountspace so Dalvik apps can mount system-wide volumes
• init.rc change: init.rc: Create /storage mountpoint so Dalvik can mark as slave in zygotes

Alternatively, ROMs that can't/prefer not to use a source-build Dalvik (libdvm), I've also provided a kernel patch that implements a similar workaround within the kernel. It also requires the above init.rc modification:

• Kernel commit: Restrict slave mountspace so Dalvik apps can mount system-wide volumes
• init.rc change: init.rc: Create /storage mountpoint so Dalvik can mark as slave in zygotes

With either of the above two fixes, CifsManager et al. should work when using a mountpoint outside /storage (and /mnt/shell/emulated). I'd recommend using "/mnt/cifs" or something similar. Attempting to mount inside /storage retains the previous behavior where the mount can not be seen by other apps.

Note that ROMs only need one of the above two fixes, although they are compatible with each other and will function correctly if both are present. The Dalvik approach is preferred over the kernel workaround where feasible. Attached are the three patches referenced in the issues/commits.

Attachments: (sry for editing the quote)
dalvik.diff: https://forum.xda-developers.com/attachment.php?attachmentid=1656555&d=1358548352
nitrc.diff: https://forum.xda-developers.com/attachment.php?attachmentid=1656556&d=1358548352
kernel.diff: https://forum.xda-developers.com/attachment.php?attachmentid=1656557&d=1358548352

Look at the attached files, the answer is in there, but i don't know what to do with it

 

[hachamacha]

Thanks. I've got to do some work from home before I go back to messing around with this. I read the zygote/Dalvik page. I'm sure I've read it before but had the impression that the information was obsolete, but maybe not!

 

[hachamacha]

I guess there a couple of problems for me with that information.

1) It is pretty old (2013 or so): I can't even find the pertinent file in my source tree anymore.
2) dalvik has undergone a lot of revisions since this was tried. I'm not at all sure the change looks very different from the way tmpfs is /storage mounted already.
(but I could try this one. I figure in real time, if it'd let me remount it with the changes, the worst it could do is lock me up).
3) the kernel I'm using doesn't appear to have that line in it, besides, I'd have to rebuild the kernel.

I guess I'd much rather find a userspace way around this problem if possible. I seems almost unthinkable that there'd be no other way (via the mount cmd for example and careful choice of mount folder) to mount something that could be seen by any process. I'll keep trying from that angle.

Regrouping: I was ssh'd into the synology server poking around when I noticed that the running nfs daemon (as shown by ps -ef | grep nfs) was nfs4. I didn't see that Android supported that so I decided to just move the entire exercise of mount.nfs4 over to Ubuntu 16.04 box.

I made sure I had all the NFS stuff installed and pretty much did these statement:
mount -t nfs -o ro x.x.x.x/share /mnt/remote # failed with bad argument
mount -t nfs4 -o ro x.x.x.x/share /mnt/remote # failed with bad argument
mount.nfs4 x.x.x.x/share /mnt/remote #failed with bad argument.

At that point I decided that android didn't matter if I couldn't figure out how to mount NFS shares from linux.

I then tried mount -t cifs -o ro,user=me,pass=pwd //server/share /mnt/remote

It mounted up immediately. I need to look up some working examples of someone using mount.nfs / 4 from anywhere to synology. While I'm sure I've used it before, I'm also pretty sure I don't recall how exactly the setup and syntax works.