NTFS issue with KDE caused by iptables loopback

New to Debian (Or Linux in general)? Ask your questions here!

NTFS issue with KDE caused by iptables loopback

Postby MinkN00b » 2017-10-26 03:35

I need someone to please explain how this is possible because I just don't understand how this is possible.

I have a minimal Debian stretch installed with sddm, plasma-desktop, ntfs-3g, konsole, dolphin, kwrite, kwin-x11, and iptables-persistent installed.
All updates have been applied.

I have a 2nd hard drive in my system (SATA) that is NTFS.
When I tried to open in with either Dolphin, Kwrite, or any other KDE app it took around 4 minutes and 20 seconds to open.
I tracked down why Dolphin, Kwrite, etc. take so long to open the NTFS 2nd hard drive in my system.
It was my iptables settings that were affecting it.

This was my original iptables setting:
iptables -P INPUT DROP
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -P FORWARD DROP
ip6tables -P INPUT DROP
ip6tables -P FORWARD DROP
ip6tables -P OUTPUT DROP

I added the loopback rule of
iptables -A INPUT -i lo -j ACCEPT
and now the drive opens instantly in all my KDE apps.

I have no idea why a firewall setting is affecting KDE's ability to open an internal SATA NTFS hard drive, but it is.

If I remove the loopback rule or set the OUTPUT rule to DROP, the NTFS slowdown reappears instantly.

Can anyone explain why an iptables rule would affect the system being able to open an internal hard drive?

Thank you in advance...
MinkN00b
 
Posts: 2
Joined: 2017-10-26 03:26

Re: NTFS issue with KDE caused by iptables loopback

Postby Segfault » 2017-10-26 15:32

You seem to forget X consists of two parts, server and client. They can run in the same machine, in this case loopback is used. (Or they can run in different machines.)
Segfault
 
Posts: 500
Joined: 2005-09-24 12:24

Re: NTFS issue with KDE caused by iptables loopback

Postby p.H » 2017-10-26 18:06

Your original iptables ruleset did not accept NEW packets in the INPUT chain, thus preventing any IPv4 communication over the loopback interface. Keep in mind that IPv4 packets sent over the loopback interface go through the OUTPUT chain and the INPUT chain, and must be accepted in both.

Some local processes may use networking to communicate with one another, or even with themselves.
I see no reason to restrict network communication between local processes and it is a common practice to allow all traffic over the loopback interface.

Now I have no clue about which piece of software requires local IPv4 communication when mounting the NTFS volume. I doubt it is ntfs-3g, but you can test by mounting the volume directly with the "mount" command instead of some fancy GUI application.

You can also do a packet capture on the loopback interface while opening the volume with a GUI application, and use "netstat" to see which processes owns the involved ports.

Segfault wrote:You seem to forget X consists of two parts, server and client. They can run in the same machine, in this case loopback is used.

AFAIK, X clients communicate with a local X server through a Unix socket. I don't even think that X listens on a network socket (TCP port 6000) in its default configuration. Mine does not.
p.H
 
Posts: 160
Joined: 2017-09-17 07:12

Re: NTFS issue with KDE caused by iptables loopback

Postby MinkN00b » 2017-11-05 02:56

This seems like a painfully inefficient method to utilize in order access an internal SATA hard drive.
Thank you both for your responses.
MinkN00b
 
Posts: 2
Joined: 2017-10-26 03:26

Re: NTFS issue with KDE caused by iptables loopback

Postby p.H » 2017-11-07 09:11

What method are you talking about, and why do you think it is inefficient ?
p.H
 
Posts: 160
Joined: 2017-09-17 07:12


Return to Beginners Questions

Who is online

Users browsing this forum: No registered users and 5 guests

fashionable