CachyOS on a laptop: troubleshooting network, NVIDIA, and brightness in XFCE4

I recently installed CachyOS on my laptop and documented the verification and post-install configuration workflow I executed. My goal with this write-up is to assist anyone configuring a similar setup on this distribution who faces hardware or local networking friction. I will skip basic installation mechanics, focusing strictly on practical system tuning.

Initial system verification#

Right after the first boot, the first thing I ran was a sequence of essential terminal commands to confirm overall system health:

uname -r && cat /etc/os-release | head -5
free -h
df -h /
systemctl is-system-running
ping -c 2 archlinux.org

The outcome was solid: kernel 7.1.3-2-cachyos active (compiled with x86_64-v3 microarchitecture tuning and the EEVDF scheduler), systemd operating normally, rapid network ping responses, root partition holding at only 4% disk utilization, and plenty of free RAM. The system foundation was ready, as detailed in the official CachyOS Wiki.

Local network setup via SMB#

The scenario#

I needed to connect this laptop to another machine on the same Wi-Fi network to transfer project files. The most practical approach was using SMB sharing via Samba, accessing folders directly from the graphic file manager.

Local network discovery#

The first step was identifying local network interfaces and IP allocation:

ip link show
ip addr show
nmcli device status

The laptop was connected to Wi-Fi with the assigned local IP 192.168.1.17/24. The wired Ethernet port (enp109s0) showed available without an active cable.

To discover active endpoints on the subnet, I ran a quick ping scan:

for i in $(seq 1 30); do
  (ping -c 1 -W 1 192.168.1.$i &>/dev/null && echo "192.168.1.$i active") &
done; wait

This discovered the default gateway (.1) and three active machines (.10, .14, .16). However, none responded with standard SMB port (TCP 445) open.

Client configuration fix#

While smbclient was preinstalled in CachyOS, the /etc/samba/smb.conf configuration file was absent by default, causing errors when querying remote shares:

smbclient -L 192.168.1.16 -N
# Output: Can't load /etc/samba/smb.conf - run testparm to debug it

When authoring /etc/samba/smb.conf, choosing protocol levels requires attention, as documented in the ArchWiki Samba guide:

sudo bash -c 'cat > /etc/samba/smb.conf << "EOF"
[global]
   workgroup = WORKGROUP
   client min protocol = SMB2_02
   client max protocol = SMB3
EOF'

The pitfall of NT1 (SMB1) vs SMB2/SMB3#

Legacy forum threads frequently suggest client min protocol = NT1. The NT1 token designates SMBv1, which was deprecated in Samba 4.11 due to severe remote vulnerabilities (such as EternalBlue exploits). Unless you are interacting with ancient NAS boxes, obsolete embedded routers, or running smbtree (which relies on NetBIOS broadcast queries), always enforce SMB2_02 or SMB3 for secure communication across modern Linux and Windows machines.

Configuring the Samba server on the target host#

Since no machine on the network had an active file-sharing service, I configured the server daemon on the second Linux laptop:

# 1. Install Samba
sudo pacman -S samba

# 2. Create the target sharing directory
mkdir -p ~/Compartilhado

# 3. Add Samba password for user
sudo smbpasswd -a $USER

# 4. Generate server configuration
sudo bash -c 'cat > /etc/samba/smb.conf << EOF
[global]
   workgroup = WORKGROUP
   security = user
   map to guest = never
   server min protocol = SMB2_02

[Compartilhado]
   path = /home/'"$USER"'/Compartilhado
   browsable = yes
   writable = yes
   valid users = '"$USER"'
EOF'

# 5. Enable and start daemons
sudo systemctl enable --now smbd nmbd

Note that smbpasswd creates dedicated credentials stored in Samba's internal database (passdb.tdb), independent of your system account password.

If the target server runs a local firewall (ufw or firewalld), grant inbound access to standard SMB ports:

# When using UFW:
sudo ufw allow 445/tcp
sudo ufw allow 139/tcp

To verify connectivity from CachyOS:

smbclient -L //192.168.1.16 -U my_user

The share appeared immediately and graphical navigation through Thunar worked without issues using the smb://192.168.1.16/Compartilhado URI.

NVIDIA driver verification#

The laptop features a dedicated NVIDIA GeForce RTX 5050 GPU. To confirm that proprietary acceleration and kernel modules integrated properly into CachyOS, I checked video subsystems:

nvidia-smi
lspci | grep -i vga
pacman -Qs nvidia
lsmod | grep -i nvidia

The nvidia-smi readout confirmed healthy operation:

• Driver release: 610.43.03 (open kernel modules, published in the NVIDIA open-gpu-kernel-modules repository).
• Xorg server consuming 233 MiB VRAM.
• Idle temperature at 51 degrees Celsius, with consumption contained at 8 W.

All required kernel modules loaded properly:

lsmod | grep nvidia
# nvidia
# nvidia_drm
# nvidia_modeset
# nvidia_uvm

CachyOS ships nvidia-utils, nvidia-settings, nvidia-open, nvidia-prime, supergfxctl, and matching kernel modules (linux-cachyos-nvidia-open) preconfigured.

Hybrid graphics power tuning with supergfxctl and PRIME#

On laptops with hybrid graphics (Intel/AMD iGPU + NVIDIA dGPU), allowing the discrete card to sit awake during desktop browsing severely harms battery longevity. CachyOS integrates supergfxctl to switch GPU profiles:

# Check current graphics mode
supergfxctl -g
# Output: Hybrid

# Switch to integrated mode (completely powers down dGPU on battery)
supergfxctl -m Integrated

# Verify PCIe runtime power management status (D3cold state)
cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_status
# Expected output when idle: suspended

Under Hybrid mode, desktop workloads run on the energy-efficient iGPU while GPU-intensive tasks can be offloaded on-demand to the NVIDIA card using the prime-run wrapper:

prime-run blender
prime-run steam

The display brightness issue in XFCE4#

The symptom#

The most noticeable usability bug was screen backlight control. The brightness applet in the XFCE4 system tray failed to adjust illumination, and keyboard hotkeys produced no change.

Root cause analysis#

I investigated the control chain across four stages:

1. Inspecting the sysfs backlight interface:

ls /sys/class/backlight/
# nvidia_wmi_ec_backlight

cat /sys/class/backlight/nvidia_wmi_ec_backlight/brightness
# 100

cat /sys/class/backlight/nvidia_wmi_ec_backlight/max_brightness
# 100

The hardware exposed nvidia_wmi_ec_backlight (associated with the firmware subsystem) rather than standard ACPI or Intel controllers.

2. Verifying file permissions:

ls -la /sys/class/backlight/nvidia_wmi_ec_backlight/brightness
# -rw-r--r-- 1 root root brightness

Here was the culprit: the brightness file was owned strictly by root:root with read-only permissions for third parties. The video group lacked write access, preventing the XFCE4 power manager from altering screen intensity.

3. Checking XFCE Power Manager state:

xfconf-query -c xfce4-power-manager -l | grep bright

Configuration keys were present, but the daemon could not persist values into the hardware node.

4. Missing userland utilities: Neither brightnessctl nor light were installed out of the box.

The permanent fix#

Resolving the issue required two steps based on the ArchWiki Backlight documentation:

Method A: Classic video group rule#

I created a udev rule granting write permissions to the video group whenever the backlight subsystem registers:

sudo bash -c 'cat > /etc/udev/rules.d/90-backlight.rules << "EOF"
ACTION=="add", SUBSYSTEM=="backlight", RUN+="/bin/chgrp video /sys/class/backlight/%k/brightness", RUN+="/bin/chmod g+w /sys/class/backlight/%k/brightness"
EOF'

sudo udevadm control --reload-rules && sudo udevadm trigger

Ensure your current user account belongs to the video group:

sudo usermod -aG video $USER

Method B: Modern systemd uaccess tag (no static group needed)#

Alternatively, you can integrate with systemd-logind seat tracking using the uaccess tag, which dynamically grants file ACL permissions to the active physical seat user:

sudo bash -c 'cat > /etc/udev/rules.d/90-backlight-uaccess.rules << "EOF"
ACTION=="add", SUBSYSTEM=="backlight", TAG+="uaccess"
EOF'
sudo udevadm control --reload-rules && sudo udevadm trigger

Installing brightnessctl and mapping hotkeys in XFCE4#

Install the lightweight control utility:

sudo pacman -S brightnessctl

You can now adjust backlight levels through terminal commands:

brightnessctl set 50%    # Set to 50%
brightnessctl set +10%   # Increase by 10%
brightnessctl set 10%-   # Decrease by 10%

To bind hardware brightness buttons without relying on the uncooperative desktop applet, map custom hotkeys directly via xfconf:

# Map brightness up key (XF86MonBrightnessUp)
xfconf-query -c xfce4-keyboard-shortcuts -p "/commands/custom/XF86MonBrightnessUp" -n -t string -s "brightnessctl set +5%"

# Map brightness down key (XF86MonBrightnessDown)
xfconf-query -c xfce4-keyboard-shortcuts -p "/commands/custom/XF86MonBrightnessDown" -n -t string -s "brightnessctl set 5%-"

Why this happens with NVIDIA on laptops#

On CachyOS laptops with modern discrete graphics, the nvidia_wmi_ec_backlight module registers under the Embedded Controller (EC) firmware layer.

The Linux kernel categorizes backlight devices by priority order in /sys/class/backlight/<device>/type:

1. firmware (highest priority, e.g., nvidia_wmi_ec_backlight)
2. platform
3. raw (lowest priority, e.g., intel_backlight, amdgpu_bl0)

Because desktop environments and compositors prioritize firmware nodes over GPU-level raw controllers, XFCE attempts to operate the NVIDIA node. Since this node initializes with strict root:root permissions, brightness adjustments fail silently. The udev rule permanently eliminates this restriction.

Post-install laptop checklist#

For anyone configuring a similar laptop setup, here is the verified order of operations:

1. System health: verify kernel version, RAM availability, and disk usage.
2. Local networking: add minimal /etc/samba/smb.conf with modern SMB2_02/SMB3 protocol standards and configure remote share permissions.
3. Graphics and power savings: audit drivers with nvidia-smi, configure supergfxctl, and test prime-run.
4. Display brightness: place udev rule in /etc/udev/rules.d/90-backlight.rules, install brightnessctl, and map shortcuts in xfce4-keyboard-shortcuts.
5. Session reload: log out and back in to apply group changes and test hotkeys.

Post-install reflections and takeaways#

CachyOS delivers a fast Arch-based foundation with noticeable responsiveness improvements. As with rolling distributions on modern laptops, hybrid and discrete hardware setups require minor manual adjustments.

The XFCE4 brightness issue with NVIDIA open drivers is quiet because it produces no visible desktop errors, failing silently due to restricted file permissions. Deploying a targeted udev rule and configuring brightnessctl permanently restores smooth hardware controls.

Frequently asked questions about CachyOS on laptops with NVIDIA and XFCE4#

Why is client min protocol = NT1 in Samba discouraged on modern networks?#

The NT1 token refers to SMBv1, which was deprecated in Samba 4.11 due to critical security risks (including vulnerabilities exploited by ransomware). In modern local networks connecting contemporary Linux or Windows machines, always configure client min protocol = SMB2_02 or SMB3.

What is the advantage of using TAG+="uaccess" over the classic video group?#

The classic chgrp video approach requires static user membership in the video group and demands a session logout/login. In contrast, TAG+="uaccess" delegates permissions dynamically to systemd-logind, granting ACL write access directly to the user active on the local seat (seat0), following modern Linux security standards.

How does CachyOS preserve battery on laptops with NVIDIA hybrid graphics?#

CachyOS includes the supergfxctl daemon. Under Integrated mode, it completely powers down the discrete GPU using PCIe D3cold power states, saving 8 to 15 watts of idle power draw. In Hybrid mode, the discrete GPU remains suspended until summoned via prime-run.

What should I do if the sysfs brightness value changes but the screen stays unchanged?#

This occurs when the kernel binds to nvidia_wmi_ec_backlight, but physical PWM backlight lines are wired to the integrated GPU (amdgpu_bl0 or intel_backlight). You can instruct the kernel to prefer native ACPI controls using the kernel boot parameter acpi_backlight=native, or disable the module by placing blacklist nvidia_wmi_ec_backlight in /etc/modprobe.d/blacklist.conf.

How can I bind brightness shortcuts in XFCE4 from the command line?#

Use xfconf-query to configure the xfce4-keyboard-shortcuts channel. Assign /commands/custom/XF86MonBrightnessUp to brightnessctl set +5% and /commands/custom/XF86MonBrightnessDown to brightnessctl set 5%-.

See also

Artificial Intelligence From Docker to bare-metal: running diffusion models on NVIDIA RTX 50 series (Blackwell) on Arch Linux

Infrastructure Running Android on Linux with Waydroid on a hybrid laptop: integrated graphics and ARM gaming

Infrastructure When battery optimization breaks the display manager: recovering from black screen in CachyOS with hybrid GPUs

This post is licensed under CC BY-NC.