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...
Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
NTFS issue with KDE caused by iptables loopback
Re: NTFS issue with KDE caused by iptables loopback
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.)
-
- Global Moderator
- Posts: 3049
- Joined: 2017-09-17 07:12
- Has thanked: 5 times
- Been thanked: 132 times
Re: NTFS issue with KDE caused by iptables loopback
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.
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.
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.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.
Re: NTFS issue with KDE caused by iptables loopback
This seems like a painfully inefficient method to utilize in order access an internal SATA hard drive.
Thank you both for your responses.
Thank you both for your responses.