<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>FnOS on Margrop Blog</title>
		<link>https://blog.margrop.net/en/tag/fnos/</link>
		<description>Recent content in FnOS on Margrop Blog</description>
		<generator>Hugo</generator>
		<language>en-US</language>
		
		
		
		
			<lastBuildDate>Wed, 15 Jul 2026 19:30:00 +0800</lastBuildDate>
		
			<atom:link href="https://blog.margrop.net/en/tag/fnos/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>Docker Pulls Keep Timing Out? How to Choose, Configure, and Verify Chinese Registry Mirrors</title>
				<link>https://blog.margrop.net/en/post/docker-mirror-source-selection-guide/</link>
				<pubDate>Wed, 15 Jul 2026 19:30:00 +0800</pubDate>
				<guid>https://blog.margrop.net/en/post/docker-mirror-source-selection-guide/</guid>
				<description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;The short answer&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;When Docker image pulls fail on a mainland China network, the image is not necessarily missing and DNS is not always the culprit. More often, the public registry path is congested, a mirror is temporarily unavailable, or the configuration was edited but Docker was never restarted.&lt;/p&gt;&#xA;&lt;p&gt;My practical recommendation is simple: open &lt;a href=&#34;https://status.anye.xyz/&#34;&gt;status.anye.xyz&lt;/a&gt; first and treat it as a “weather report” for Docker mirrors; select a recently healthy HTTPS endpoint; edit the correct daemon configuration for your operating system; validate the JSON; restart Docker; and finally verify with a real pull of a small image.&lt;/p&gt;</description>
			</item>
			<item>
				<title>RAID Is Not Backup: How to Choose the Right NAS Layout for Synology, fnOS, and Unraid</title>
				<link>https://blog.margrop.net/en/post/nas-raid-selection-guide/</link>
				<pubDate>Sat, 11 Jul 2026 12:00:00 +0800</pubDate>
				<guid>https://blog.margrop.net/en/post/nas-raid-selection-guide/</guid>
				<description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;The short answer&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;RAID primarily keeps a NAS available when one or more drives fail. Backup restores data after deletion, ransomware, filesystem damage, theft, fire, or a failed NAS. You normally need both.&lt;/p&gt;&#xA;&lt;p&gt;On Synology, SHR-1 is the practical default for many homes, while larger and more critical arrays deserve SHR-2 consideration. On fnOS, choose the filesystem, storage mode, drive count, and backup destination as one design. On Unraid, understand that the classic Array is not a conventional striped RAID: data disks keep independent filesystems while one or two parity disks provide failure recovery.&lt;/p&gt;&#xA;&lt;p&gt;A useful starting rule is: mirror two-drive systems; use single-drive redundancy when capacity matters and a separate backup exists; seriously consider dual-drive redundancy as drive count and individual drive capacity grow. Anything irreplaceable still needs an offline or off-site copy.&lt;/p&gt;&#xA;&lt;/blockquote&gt;</description>
			</item>
	</channel>
</rss>
