Can't Get Samba Permissions Correct
-
@thanksaj said:
I'm using the Linux box as a gateway device basically. I can share a share...it's just writing to the shared share.
Why?
-
@scottalanmiller said:
@Dashrender said:
I'm assuming you're mounting the NASs via SAMBA/CIFS to the Linux box, perhaps you can't share a share? I wonder if it's a shortcoming in the protocol - though normally I can't see why you'd want/need to do this, but in your case with Pertino, I understand.
Like proxying a share?
I guess - he's trying to provide access to the NASs to remote devices through Pertino. From his other thread since Pertino does not have a gateway device. How else could he gain access other than to 'share a share'?
-
@Dashrender said:
I guess - he's trying to provide access to the NASs to remote devices through Pertino. From his other thread since Pertino does not have a gateway device. How else could he gain access other than to 'share a share'?
Install Pertino on the NAS.
-
Or use a TCP hairpin.
-
-
@Dashrender said:
@scottalanmiller said:
Or use a TCP hairpin.
a what? I'll look it up.
A tiny piece of code that does a network hairpin. Basically a dumb proxy. You connect in one port and all it does is redirect your code to a service on another system. Allows you to access the resource like you are local. Kind of like what AJ is doing with the Samba system, but without all of the overhead and complexity of mounting and rehosting the share with a full Layer 7 network stack and application handling issues. A hairpin can't modify what is happening, it's just a tiny tunnel that handles a network redirect.
-
I don't understand how that would work?
The traffic on the Pertino network leaves my machine goes into the Pertino (what I'll call) cloud switch and goes directly to the device he desires to see. Where would the hairpinning code go that would allow him direct access to the NASs?
Of course, if he can install the Pertino client on the low end NASs he purchased, that would solve this whole problem.
-
@Dashrender said:
I don't understand how that would work?
It's a lot like an unsecured VPN. There is no tunnel point to point, just a little "elbow tunnel" that traffic goes into and out of immediately. It makes remote clients look like they are on the local network to the servers. You can do this with tools like SSH or NC.
-
@Dashrender said:
The traffic on the Pertino network leaves my machine goes into the Pertino (what I'll call) cloud switch and goes directly to the device he desires to see. Where would the hairpinning code go that would allow him direct access to the NASs?
You put in somewhere on the LAN. The remote machine on Pertino would point to the machine with the hairpin via Pertino. That machines, being on the LAN with the file server (NAS) would then see the fileserver locally not via Pertino.
It is a little like building your own, specialty, Pertino gateway.
-
@Dashrender said:
Of course, if he can install the Pertino client on the low end NASs he purchased, that would solve this whole problem.
Can be done on many of them, in theory. Just have to use the Tarball install method.
I'm trying to talk Pertino into making Netgear ReadyNAS and Synology packages that are managed by those vendor's app stores to make it dead simple to install it rather than having to work through things.
-
@scottalanmiller said:
@Dashrender said:
The traffic on the Pertino network leaves my machine goes into the Pertino (what I'll call) cloud switch and goes directly to the device he desires to see. Where would the hairpinning code go that would allow him direct access to the NASs?
You put in somewhere on the LAN. The remote machine on Pertino would point to the machine with the hairpin via Pertino. That machines, being on the LAN with the file server (NAS) would then see the fileserver locally not via Pertino.
It is a little like building your own, specialty, Pertino gateway.
So AJ should look at setting up a hairpin on his linux box instead of mapping it? Or setup a second linux vm that would do nothing more than act as a packet forwarder(hairpinning)? So in these cases the linux boxes are just routers, and the SAMBA portion is not used or interfering.
-
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
The traffic on the Pertino network leaves my machine goes into the Pertino (what I'll call) cloud switch and goes directly to the device he desires to see. Where would the hairpinning code go that would allow him direct access to the NASs?
You put in somewhere on the LAN. The remote machine on Pertino would point to the machine with the hairpin via Pertino. That machines, being on the LAN with the file server (NAS) would then see the fileserver locally not via Pertino.
It is a little like building your own, specialty, Pertino gateway.
So AJ should look at setting up a hairpin on his linux box instead of mapping it? Or setup a second linux vm that would do nothing more than act as a packet forwarder(hairpinning)? So in these cases the linux boxes are just routers, and the SAMBA portion is not used or interfering.
I guess I'm still confused how the hairpin differs from what I'm already doing. Besides, I would like this to be secure over Pertino.
-
Hairpin still requires the use of Pertino. The difference from what I read, Scott will undoubtedly correct me if I'm wrong ;), is that the linux box that you're Pertino'ing to does nothing more than pass traffic from the Pertino client to the desired IP.
Like a firewall with port forwarding/NAT enabled, the linux box would simply get a request for the IP/port of the NAS and forward that request to the NAS.
-
@Dashrender said:
Hairpin still requires the use of Pertino. The difference from what I read, Scott will undoubtedly correct me if I'm wrong ;), is that the linux box that you're Pertino'ing to does nothing more than pass traffic from the Pertino client to the desired IP.
Like a firewall with port forwarding/NAT enabled, the linux box would simply get a request for the IP/port of the NAS and forward that request to the NAS.
Oh ok, so if you use a Linux box as a hairpin, you can only use it to one IP?
-
@thanksaj said:
@Dashrender said:
Hairpin still requires the use of Pertino. The difference from what I read, Scott will undoubtedly correct me if I'm wrong ;), is that the linux box that you're Pertino'ing to does nothing more than pass traffic from the Pertino client to the desired IP.
Like a firewall with port forwarding/NAT enabled, the linux box would simply get a request for the IP/port of the NAS and forward that request to the NAS.
Oh ok, so if you use a Linux box as a hairpin, you can only use it to one IP?
Great question - I guess that would depend... I know Linux can be multi-homed (i.e. have more than IP address) but the question is, will Pertino see all local IPs and route traffic for those IPs as such? If yes, then you can probably get away with one linux box, otherwise you'll need multiple.
-
I haven't actually used Pertino yet so this brings a question to mind.
When you are on a remote machine using Pertino to say a server in your office, when you connect to that server, what IP are you using? The servers real IP or the Pertino one?
Like the above mentioned hairpinning, it's my understanding the Pertino kinda does the same thing - The Pertino client on the server has it's own IP address which is registered into the Pertino cloud, Does the Pertino client have a translation list of Pertino IPs to actual device IPs, and all the end user has to use are the real IPs? I also THINK (but could be wrong) that Pertino allows the use of your own DNS servers, so if you ping server.company.com it will check your internal DNS server in the office for the real IP of the server and Pertino acts like an invisible switch just making sure the traffic gets to the correct box.
Is that right?
-
@Dashrender said:
I haven't actually used Pertino yet so this brings a question to mind.
When you are on a remote machine using Pertino to say a server in your office, when you connect to that server, what IP are you using? The servers real IP or the Pertino one?
Like the above mentioned hairpinning, it's my understanding the Pertino kinda does the same thing - The Pertino client on the server has it's own IP address which is registered into the Pertino cloud, Does the Pertino client have a translation list of Pertino IPs to actual device IPs, and all the end user has to use are the real IPs? I also THINK (but could be wrong) that Pertino allows the use of your own DNS servers, so if you ping server.company.com it will check your internal DNS server in the office for the real IP of the server and Pertino acts like an invisible switch just making sure the traffic gets to the correct box.
Is that right?
Pertino has to be on both the source and destination device. Every Pertino network uses the 50.203.224.0 network, so the Pertino adapter, either in Windows or Linux or whatever, uses that IP. You can go by hostname or the Pertino IP. So if I ping plex-server from my work computer, which has Pertino on it, it will ping the Pertino adapter of the remove device. It's a split-stack method of VPN.
-
I realize that Pertino has to be on both sides. If you're on your remote device and you ping the real internal IP of the server in your office (assuming Pertino is installed there as well) will you get a response? I thought you would.
-
From my understanding a hairpin is basically a network bridge like a router. It just takes all info going in and passes it to the appropriate point on the other side.
On your linux server does the Pertino connection appear as an independent interface?
-
@coliver said:
From my understanding a hairpin is basically a network bridge like a router. It just takes all info going in and passes it to the appropriate point on the other side.
On your linux server does the Pertino connection appear as an independent interface?
This is not the case for a router like an ASA. A hairpin for an ASA is in interface and back out that same interface. No bridging at all.
