Linux Quiz

600 breaks down as: owner gets read and write, and literally everyone else (group, other) gets nothing at all. SSH actually enforces this for private keys specifically, it will flat-out refuse to use a key file that's readable by anyone besides its owner.

These three settings attack the same problem from different angles: widening the ephemeral port range gives you a bigger pool of ports to use for outgoing connections, shortening tcp_fin_timeout means closed sockets don't linger in TIME_WAIT as long, and tcp_tw_reuse lets the kernel recycle those TIME_WAIT sockets for new connections sooner. Together, they meaningfully relieve port exhaustion under high connection churn.

Host key warnings exist specifically to protect you from man-in-the-middle attacks, so turning that checking off everywhere throws away the exact protection host keys provide. Pushing the correct, updated known_hosts entries out to everyone (or moving to CA-signed SSH certificates) fixes the warnings without giving up that protection.

The sticky bit on a world-writable directory like /tmp stops one user from deleting or renaming another user's files, even though the permissive rwx would otherwise allow it. Without it, anyone with write access to the directory could remove files they don't own, which would make a shared temp directory unsafe. Option B describes the setgid bit on a directory instead, a completely different permission bit.

NFS connectivity problems and timeouts are typically recorded directly in the kernel's own log (dmesg/journalctl), which is exactly where you'd look first to understand what's actually happening. Jumping straight to deleting the user's home directory or restarting the whole server skips real diagnosis entirely and risks losing data for no reason.

Running ulimit interactively only changes the limit for THAT shell session and whatever it spawns afterward, it's completely forgotten the moment you log out or reboot. To make a higher file-descriptor limit stick permanently for a user or service, it needs to be configured in limits.conf (or the equivalent systemd setting for a service), not set ad hoc in a terminal.

ss -tlnp lists exactly what you need in one shot: every TCP socket currently listening, and which process owns it, so you can immediately see if port 8080 is already taken before you try to bind your own service to it.

dd's writes don't go straight to the physical disk, they land in the page cache (RAM) first, and the command returns as soon as they're buffered there, not once they've actually hit the platter. That's why the reported speed looks suspiciously fast, it's really measuring RAM bandwidth, and only an explicit sync afterward forces those buffered writes out to real disk.

D state means the process is stuck waiting on the kernel for an I/O operation to finish, and that wait genuinely cannot be interrupted, not even by a kill -9. The real problem is whatever it's stuck waiting ON (a hung NFS server, a failing disk), so the fix is digging into logs like dmesg to find and address that underlying issue, not fighting the stuck process itself.

The permissions shown (rw-r--r--) simply never included execute for anyone, that's the whole problem. You already own the file, so chown changes nothing, and sudo just runs the command as root, it doesn't add an execute bit, the script still needs one to be runnable at all, which is exactly what chmod +x adds.