Mounting share from another NAS works for some, but not others
I run OwnCloud on a NAS other than my primary one and have some folders mounted (as read-only, if it matters) on that NAS from my main NAS so that OwnCloud can serve them up without having to duplicate the files on the NAS runing OwnCloud. I also ran a test to see if ReadyDLNA could see them. Both definately used to work. But for some reason, one mount no longer does. I get the following when I try to ls the mount point: ls: cannot open directory '/data/Videos/MyVideos': Permission denied I actually don't use this one much (it was mainly for the DLNA test), so I have no idea what I have done to either NAS since it worked.
Basically, my main (target) NAS Music/Music folder is mapped and working on my OwnCloud (client) NAS but my /Videos share is not working.
I use NFS for the export, and both shares have the same NFS settings. /etc/exports on the target NAS confirms this: "/data/Music" *(insecure,insecure_locks,no_subtree_check,crossmnt,anonuid=99,anongid=99,root_squash,rw,async) "/data/Videos" *(insecure,insecure_locks,no_subtree_check,crossmnt,anonuid=99,anongid=99,root_squash,rw,async)
They are both mounted via /etc/fstab on the client NAS: 192.168.0.42:/data/Music/Music /ext/AllMusic nfs ro 0 0 192.168.0.42:/data/Videos /data/Videos/MyVideos nfs ro 0 0 The mount points on the client NAS exist and are empty.
I also tried the following on the client NAS: mount 192.168.0.42:/Videos /data/Videos/MyVideos And got this response. mount.nfs: access denied by server while mounting (null)
I created a mount point in /ext for the Videos share (since that works for the Music share) and only did the manual mount, and I got the same error, but ls just shows the mount point empty rather than giving an error. I also tried to mount a sub-directory of the remote Videos share, and it made no difference. I removed the mouting of the Videos share from fstab and re-booted, which cleared up the error when I ls the mount point, but it made no difference in manually trying to mount the share. Rebooting either NAS made no difference.
The problem appears to be with the main (target) NAS, but I have no idea what the cause is. Anyone have any idea what it might be?
I use NFS for the export, and both shares have the same NFS settings. /etc/exports on the target NAS confirms this: "/data/Music" *(insecure,insecure_locks,no_subtree_check,crossmnt,anonuid=99,anongid=99,root_squash,rw,async) "/data/Videos" *(insecure,insecure_locks,no_subtree_check,crossmnt,anonuid=99,anongid=99,root_squash,rw,async)
They are both mounted via /etc/fstab on the client NAS: 192.168.0.42:/data/Music/Music /ext/AllMusic nfs ro 0 0 192.168.0.42:/data/Videos /data/Videos/MyVideos nfs ro 0 0 The mount points on the client NAS exist and are empty.
I also tried the following on the client NAS: mount 192.168.0.42:/Videos /data/Videos/MyVideos And got this response. mount.nfs: access denied by server while mounting (null)
I am rather confused here, because ReadyDLNA folders aren't shares - they are just collections of media that have the same type that are advertised using the DLNA protocol. So they shouldn't exist on /data at all.
If you look on the source NAS with ssh, you are seeing /data/Videos and /data/Music subvolumes???
I am rather confused here, because ReadyDLNA folders aren't shares - they are just collections of media that have the same type that are advertised using the DLNA protocol. So they shouldn't exist on /data at all.
If you look on the source NAS with ssh, you are seeing /data/Videos and /data/Music subvolumes???
Yes, ReadyDLNA folders are not shares. But what I was testing is if ReadyDLNA would see the files on the external share and list them, which it did. It "sees" the shared shares when they are mounted within a share that has ReadyDLNA enabled.. I guess I could have been more clear on that.
Everything looks right on the source NAS via the GUI and SSH. I haven't tried creating any new shares to see what happens with them. I was hoping somebody could help point the way to limit the number of experiments I need to try.
I am rather confused here, because ReadyDLNA folders aren't shares - they are just collections of media that have the same type that are advertised using the DLNA protocol. So they shouldn't exist on /data at all.
If you look on the source NAS with ssh, you are seeing /data/Videos and /data/Music subvolumes???
Yes, ReadyDLNA folders are not shares. But what I was testing is if ReadyDLNA would see the files on the external share and list them, which it did. It "sees" the shared shares when they are mounted within a share that has ReadyDLNA enabled.. I guess I could have been more clear on that.
VIdeos and Music are both default names of media types - which should always show up over ReadyDLNA no matter what the underlying shares are called. I'd first try renaming the two shares to something unique, and then retest what happens on the ReadyDLNA side of things.
FWIW, I think ReadyDLNA should find the files just fine, and the folder view should also work. But I don't see why it would do anything related to the NFS export, as it doesn't depend on NFS. It's just using the DLNA protocol itself. But I also don't see why OwnCloud would be changing the exports. So it is a bit of a puzzle.
VIdeos and Music are both default names of media types - which should always show up over ReadyDLNA no matter what the underlying shares are called. I'd first try renaming the two shares to something unique, and then retest what happens on the ReadyDLNA side of things.
FWIW, I think ReadyDLNA should find the files just fine, and the folder view should also work. But I don't see why it would do anything related to the NFS export, as it doesn't depend on NFS. It's just using the DLNA protocol itself. But I also don't see why OwnCloud would be changing the exports. So it is a bit of a puzzle.
The mount point that's not working is under the standard Videos share (/data/Videos), and is named "MyVideos". But I also tried mounting to /ext/Test, and it made no difference.
NFS export and the mount on the other NAS have everything to do with it. I don't know for sure which is not working right, but it appears that it's the export from the target, not the mounting by the client. The files are not on the client NAS running ReadyDLNA and OwnCloud, they are on the target NAS that has shares/folders exported and then mounted (via NFS) on the client NAS that's running those programs. ReadyDLNA is not enabled on the target system, nor is it runing OwnCloud. OwnCloud isn't changing anything, so I don't know where you got that impression. Everything that gets mounted properly is visible to and available through OwnCloud, while the content of the share where the mount fails is, of course, not available. I'm not even running ReadyDLNA right now, it only really seemed important because I need to put the mount point somewhere it can see, where I can put them in /ext for OwnCloud. One is visible to the GUI, and the other not; and that could make a difference if the problem is on the client.
Basically, instead of using a PC or a RasPi to run the apps that "serve up" files on the NAS, I'm using another NAS (a Pro2 running OS6) to do that, as I have spares and figured I'd put one to use. The ReadyNAS version of OwnCloud doesn't have the normal "external shares" provision working for remote shares, so I use this method to access shares that are "external" to OwnCloud (not in it's directory path) but "local" (via an NFS mount) to that NAS. Somewhere along the line, it stopped working for one share, but not two others (I listed only one example that works above).
NFS export and the mount on the other NAS have everything to do with it.
Sorry, I wasn't being very clear. Obviously the issue is that the NFS export/mount is failing. But I don't see how that failure could be caused by ReadyDLNA.
Though maybe you were just saying that because the mount failed, neither ReadyDLNA nor OwnCloud could access the files on the remote NAS???
Does showmount -e 192.168.0.42 complete, or does it hang?
Maybe also look for rpc.mountd errors in the logs?
