Nas

前言 群晖Nas，自带DSM零碎，DiskStation Manager (DSM)是网页界面的直觉式操作系统，可帮忙用户治理存于Synology DiskStation和RackStation里的文件、照片、音乐、视频以及其余重要内容。DiskStation Manager可实现的不仅是存储材料，用户还能够自行设置应用程序与抉择所须要的服务，更加地丰盛生存并进步工作效率。我是2019 年 9 月 20 日买了一台DS218+，截止目前曾经用了快三年了。平台次要用于文件存储，当初因为装了电信的宽带开明了公网IP，可玩性就更大了，明天就分享一下我用群晖次要做了些什么。 设施介绍 DS218+，2盘位，6GB内存，买了两块4T的狼盘，待机功率4.41W。 我的玩法近程拜访 因为我的宽带是电信的宽带，并且开明了公网IP，用的是斐讯K3的路由器，加上Openwrt的路由器固件，通过路由器拨号+动静DNS+端口转发的形式，能够实现外网拜访，所以群晖、路由器的治理都能够实现近程。 当然如果没有公网IP，也能够通过frpc、zerotier、ddnsto等一些其余的内网穿透工具实现公网拜访。这里我次要介绍一下如何利用Openwrt+动静DNS+端口转发的形式实现近程拜访。 路由器拨号 个别默认装宽带的时候徒弟都会应用的是光猫进行拨号上网，而后连贯路由器通过DHCP的形式进行网络连接，这样的话咱们的路由器上拿到的IP地址就只是内网的IP地址，个别是192.168.x.x这样子，要实现公网IP近程拜访，就须要将光猫连贯上网形式改为桥接，路由器上进行拨号，不同的光猫批改形式基本一致，次要是须要应用超级管理员形式登陆，这里为大家提供了不同运营商超级管理员的账号和明码，具体如何设置大家自行百度即可。 中国电信：telecomadmin nE7jA%5m中国联通：CUAdmin CUAdmin 或 CUadmin中国移动：CMCCAdmin aDm8H%MdA 或 CMCCAdmin WoTf6&$7光猫改为桥接后，在路由器中，找到网络-接口，设置wan接口，通信协议抉择PPPoE，PAP/CHAP 用户名就是宽带账号，PAP/CHAP 明码就是宽带明码高级设置中依据理论须要设置，物理设置中依据理论你路由器与光猫连贯的端口进行设置，个别默认即可。设置实现后，点击保留利用就实现了路由器拨号。拨号胜利后，就能够接口那个界面看到pppoe端口的IPv4地址，就是公网IP的地址了。 设置端口转发 在网络-防火墙-端口转发中设置须要转发的端口，这里因为我的群晖内网地址是192.168.2.16，路由器的内网地址是192.168.2.1，这里转发了所有群晖外面的端口，以及9999到路由器的端口 当然也能够依据理论须要，并不是所有的端口都要转发，依据须要增加即可，比方只转发mongodb的端口： 在这里设置端口转发后，通过下面路由器拨号获取的IP地址，加上这里的端口，就曾经能够实现近程拜访了。比方我的公网IP地址是10.23.122.11，转发了mongodb的端口是27017，外部对应的地址是群晖的IP192.168.2.16，外部的端口是群晖外面mongodb的端口27017，则通过10.23.122.11:27017就能连贯到群晖的mongodb服务实现近程拜访群晖的mongodb。同样的，如果你须要mysql 3306端口也能够这样设置。 值得注意的是，运营商是没有开明443和80端口的，因而这里内部端口不能设置443或80 通过上述设置，就能够实现近程拜访群晖外部的各个服务了，指不定如果你的路由器重启了，那么pppoe的拨号也会变，因为运营商个别给的都是动静IP段地址，每次重启后获取的IP地址都会和上次不一样，因而咱们就须要通过动静DNS来绑定域名的形式进行拜访咱们的外部服务。 设置动静DNS openwrt的动静DNS是一个插件，个别路由器固件都会自带，如果没有的话须要本人装置，具体不同架构的安装包能够在这里下载：https://op.supes.top/packages/。动静DNS的次要作用是通过为IP地址绑定域名，在IP地址动态变化的时候，咱们依然能够通过主动绑定的域名进行拜访。 找到服务-动静DNS，这里我曾经增加过了，如果须要新增加则在上面新加一项即可。须要留神的时候，增加域名的过程是须要获取对应的域名提供商提供的accessKey的，这里我用的是阿里云的域名。 关上后在根本设置中，设置相干的配置 勾选已启用查问主机名：就是你要设置的域名，比方设置的是nas.wangbo.siteIP地址版本：IPv4地址DDNS服务提供商：因为我的是阿里云，所以抉择aliyun.com，依据本人的域名服务商设置域名：与查问主机名统一用户名：阿里云的AccessKeyID明码：阿里云的AccessKeySecret，具体查看形式见下图应用Https：勾选CA证书门路：放弃空就行 通过上述设置后，阿里云的域名解析零碎就会主动解析并绑定域名，在域名控制台就会看到它曾经增加了一项A记录，并且每次路由器中的IPv4变动后，两分钟内它都会自动更新。 以上就是我所应用的近程拜访的形式，当然如果你没有公网IP的话，相对来说会比拟麻烦，如果应用frpc的话须要有一台有公网IP的服务器进行转发，应用zerotier的话须要在路由器和nas上都装置插件才能够，其余如ddnsto是应用了他们提供的域名和端口，无奈转发像mysql、mongo这种服务，相对来说不是很不便，当然如果有钞能力都不是问题，因为有很多内网穿透的服务商能够帮忙你，如花生壳什么的，依据本人须要即可。 近程拜访设置实现后，咱们就能够开始折腾群晖下面的货色了。 套件 群晖DSM零碎上为大家提供很多的套件，能够在这里查看，同时一些大佬也为无偿提供了一些更好用的套件，如云梦、矿神、裙下孤魂等等等等，咱们只须要通过简略的设置就能够应用他们提供的套件了。 套件源配置 关上群晖的套件核心，点击右上角设置-套件起源，配置对应的套件源地址即可。下面三位曾经为大家提供了丰盛的套件，间接应用即可。另外，群晖自身其实也提供了很多好用的套件。上面次要分享一下我日常应用的套件。 罕用套件阿里云盘 WebDev 矿神提供，配置好源之后间接下载，依据矿神的文档进行配置即可。aria-label="阿里云盘 WebDAV 服务，次要应用场景为配合反对 WebDAV 协定的客户端 App 如 Infuse、nPlayer 等实现在电视上间接观看云盘视频内容， 反对上传文件，但受限于 WebDAV 协定不反对文件秒传。套件应用教程：https://imnks.com/3939.html Cloud Sync 群晖自带，套件核心间接下载安装即可，能够同步超多云平台，将文件同步到Nas中，十分好用，具体配置也很简略。 ...

Unraid 是一个家用 NAS 零碎，也是我第一次接触 NAS，因为有敌人在用，所以也没思考其余 NAS 零碎。应用两年，体验极好，特此记录，以便分享。 文件共享性能的应用内网千兆的 SMB 网盘，简直所有数码设备都原生反对。 配合 OpenVPN 能够在里面拜访。装一个 WebDAV 能够实现 HTTP 拜访。重要数据切勿裸露到外网以 Mac OS Finder 为例： 同一个局域网内，会收到播送，间接侧边栏寻找即可。如果没找到或者是在里面通过 VPN 拜访，点击“返回 > 连贯服务器”，依据协定输出 URL 即可在侧边栏找到： 点击左下角“+”能够珍藏地址。自带奇偶校验，随便一块硬盘坏了都能够间接用新硬盘复原。大大晋升容错性。配合 RClone 定期备份到 OSS。自带权限治理。能够给 Mac 当 Time Machine 备份盘，全程无线备份，开启主动备份实现无感。配合 OpenVPN 能够实现近程复原。小米摄像头贮存监控视频。虚拟机软路由 OpenWrt这个步骤须要买网卡硬件，而后直通给虚拟机，参考 B 站司波图的教程。 DDNS：用于将域名主动解析到正确的公网 IP，因为电信宽带的公网 IP 隔三差五就会变动，而且固定公网 IP 太贵了。OpenClash：迷信上网。其余插件还没有精力、或者临时没需要钻研，比方广告屏蔽、流量管控等。OpenVPN用于在里面连贯到家里的内网，包含 SMB 网盘、迷信上网。因为 docker 版本曾经不再保护，所以装到虚拟机了。 之前装过 OpenConnect，默认会把本地的路由表干掉，不好用。 如果你还没装的话，举荐 Unraid 内置的 WireGuard 代替，有如下几个特点，能够本人衡量一下： 配置过程十分简略迅速，我只用了一个多小时（其实看文档配置只用了十来分钟，我遗记关上右上角的开关了所以 debug 了老半天）。OpenVPN 我配了大半天，而且步骤繁琐，报错多。配置文件（peer）间接连贯，不须要账号密码，一个用户一个配置文件。而 OpenVPN 是对立的配置文件，通过账号密码来二次验证。不能多端同时登录？能够配置多个 peer 解决。揭示：无论是 OpenVPN 还是 WireGuard 的客户端都须要一个非中国区的 Apple ID。 ...

0.根底环境类别：笔记本型号：中国长城 UF712硬件平台：飞腾处理器（ArmV8 指令集）零碎：河汉麒麟操作系统 V10 SP1(2203) 关键词：信创,麒麟零碎,linux,PKS,河汉麒麟,飞腾,arm64,arm,NAS,群晖,synology 1. 需要背景如果咱们有多处办公须要，有多台电脑须要同步文档资料，平时不太想背着笔记本到处跑。这个时候，群晖的Drive进行同步，能够依据须要设置两台或两台以上电脑进行指定文件夹材料同步。注：自己是群晖DS218j,其余型号或其余品牌NAS，请参照解决。 2. 群晖Synology Drive下载及挪动文件夹阐明关上群晖下载站https://www.synology.cn/zh-cn...群晖提供了Linux下的桌面程序，但仅针对x86平台，并没有针对arm平台做解决。因而在飞腾的处理器平台上（如果是X86硬件平台，能够间接应用桌面版），本文将应用安卓挪动APP来解决这个材料同步的问题。注：请在利用商店中，装置筹备好挪动运行环境下载实现后，双击APK程序安装。上面是挪动环境所在文件夹/var/lib/kmre/var/lib/kmre/data/kmre-1000-long这一个相当于手机中的数据盘根目录/var/lib/kmre/data/kmre-1000-long/0-麒麟文件而这个，则是映射的集体主文件夹/home/long（留神，要记分明这些，前面咱们映射时为了省事，所有挪动利用的材料都会间接放在这里） 3.Synology Drive设定启动利用，输出ID，用户名，明码进入点击更多点击挪动备份工作点击同步工作点击+号，减少同步工作（我在集体主文件夹的文档中新建了synologyfiles目录，用于同步）设置好服务端目录，和本地目录设置好相应的参数保留确认即可。成果如下： 胜利后，就能够和其余的windows，linux电脑，各个中央的电脑同享一份文件夹，不便日常工作啦。 麒麟零碎专栏：https://segmentfault.com/blog...文章发表在SegmentFault分割邮箱：1179611323@qq.com群：662512340 文章中相干材料均可通过群文件获取或向群主申请帮助发行日志：20220727 首发

0.根底环境类别：笔记本型号：中国长城 NF14C硬件平台：飞腾处理器（ArmV8 指令集）零碎：河汉麒麟操作系统 V10 SP1(2203) 关键词：信创,麒麟零碎,linux,PKS,河汉麒麟,飞腾,arm,NAS,NFS,群晖 1. 需要背景群晖目前提供的客户端都是Linux x86系列，windows,android/ios。没有针对arm系列做客户端，失常状况下，都是通过web拜访其治理后盾进行拜访。本文试图通过NFS形式将其挂载在零碎下，方便使用。其余类型的NAS能够参考设置。 2.群晖设置2.1 NFS设置关上群晖web治理页面关上控制面板找到文件服务找到nfs服务菜单项关上nfs服务，抉择v4协定并利用NFS协定设置结束 2.2 共享文件夹设置关上控制面板找到共享文件夹服务进入共享文件夹列表选中要共享的文件夹后，点击操作栏的 【编辑】 按钮点新增依据理论状况设置相干信息，其中要求大抵为：IP设置：输出将访问共享文件夹之 NFS 客户端的 IP 地址。您能够用以下三种形式填写此栏： 繁多主机：齐全限定域名 (FQDN) 或 IP 地址。通配符：，.synology.comIP 网络：203.74.205.32/255.255.252.0, /24权限：抉择 NFS 客户端的读写权限。安全性：指定要施行的平安类型。AUTH_SYS：应用 NFS 客户端的 UID(用户标识符)和 GID(群组标识符)来查看拜访权限。Kerberos 验证： 当 NFS 客户端连贯到共享文件夹时执行 Kerberos 验证。客户端必须通过 Kerberos 验证能力访问共享文件夹。Kerberos 完整性：传输数据时执行 Kerberos 验证并确保数据包的完整性。Kerberos 隐衷性：传输数据时执行 Kerberos 验证并对 NFS 数据包进行加密，从而避免别人歹意烦扰 NFS 通信。Squash：此栏可让您管制 NFS 客户端用户的拜访权限。请抉择下列操作之一： 无映射：容许 NFS 客户端的所有用户(包含 root 用户)保有原始拜访权限。映射 root 为 admin：将拜访权限调配给 NFS 客户端的 root 用户，相当于您零碎中的 admin 用户拜访权限。映射 root 为 guest：将拜访权限调配给 NFS 客户端的 root 用户，相当于您零碎中的 guest 用户拜访权限。映射所有用户为 admin：将拜访权限调配给 NFS 客户端的所有用户，相当于您零碎中的 admin 用户拜访权限。异步：勾选此选项可让您的 Synology NAS 在实现对文件的更改之前回复来自 NFS 客户端的申请，以取得更好的性能。容许非特权端口：勾选该选项可让 NFS 客户端应用非特权端口(即大于 1024 的端口)连贯到 Synology NAS。Squash中的设置很重要，不然映射了没有权限而拜访不了。最初，点击确定即可实现共享文件夹的相干设置。 ...

前言不晓得有多少人在家里搭建地方存储设备的，也就是NAS。这个货色在我日常生活中，存储了大量的个人资料，家人们的照片，技术的材料，还有各种高清影视剧。搭配公网的IP，能够真正做到，任何时候任何地点的读取材料的需要。 我之前玩NAS写过一篇基础性的介绍文章，包含公网的申请和端口映射，有趣味的小伙伴能够读下： https://mp.weixin.qq.com/s/Mw... 然而应用NAS一段时间后，尽管能够随时随地的对文件进行读取和保留。然而我发现还是有很多不不便的中央。 比方我电脑里的一个材料在公网环境要从NAS读取（留神是公网，内网其实怎么样都行），碰到了以下几个麻烦： 1.关上NAS的治理界面，进行受权登陆，把文件下载到本地运行。如果文件小倒还没事，如果文件体积一大，比方一部电影20个G，那我必须等电影全副下载到本地才能够观看。 2.群晖NAS提供了Synology driver文件同步工具，每台电脑上须要装一个客户端软件，A电脑同步下来，B电脑启动时还要期待Synology driver同步下来能力应用文件。我总感觉这种形式尽管可行，但还是太麻烦，还要通过第三方同步软件的反对才能够用。不原生。 3.如果是通过ftp，sftp等这种形式进行挂载拜访，也是一样的问题。无非就是把网页的受权登陆换成了ftp的受权。而且ftp如同也不反对流形式的读取，电影无奈间接读取播放。 4.至于smb协定形式，把smb映射到公网存在安全隐患。况且smb的传输效率也很低。 所以我起初都采纳webdav协定进行挂载，把nas挂载老本地的一个网络硬盘进行拜访。这种形式我始终感觉是最好的形式，因为相当于间接在本地进行了NAS磁盘的操作。也能以流的形式播放影视资源。多台电脑，也能同时挂载，这里存进去，那里就能实时读取到。相当便捷。 然而在应用webdav的时候我也发现一些弊病，比方有些软件或者游戏是不反对间接装在网络磁盘里的。 我于是就想，如果零碎能把网络磁盘当做是本人本地的磁盘。那就完满了。 就在前段时间，一个老哥和我介绍了iSCSI这个协定，还真能实现这样的骚操作。我钻研了当前，胜利的把NAS的一部分磁盘空间完满的挂载到了本地，并且，零碎会把这个磁盘完完全全当做是本地的磁盘空间。我的macbook pro霎时扩充了一个T的容量！ 好啦，前言有点长，所以，这篇文章就是给玩NAS的同学介绍下iSCSI协定的玩法。 什么是iSCSIiSCSI（Internet Small Computer System Interface即Internet小型计算机系统接口），是一种在TCP/IP上进行数据块传输的规范，是由CiSCO和IBM两家公司发动的，并且失去了各大存储厂商的大力支持。iSCSI将SCSI命令封装于TCP/IP包之中，并且应用了一个SCSI帧头。iSCSI能够实现在IP网络上运行SCSI协定，使其可能在诸如高速千兆以太网上进行疾速的数据存取备份操作，也就是基于网络的存储。这是对于iSCSI的解释，我给大家翻译一下： 首先iSCSI是一种通信传输的协定规范，基于以太网进行数据传输，且传输速率十分高。其次目前很多零碎的存储底层都反对这种协定，很多零碎底层也反对这种协定，比方windows，macOS。所以这种协定，可能被零碎的存储底层所辨认，从而从内核层面进行挂载。这种挂载模式会被零碎认为是本地的磁盘，然而走的却是网络传输协定。 一句话：操作系统原生的把NAS当做是本人本地的硬盘。装置软件游戏都没问题。 接下来就开搞，设置次要分2个端，服务端(NAS)和客户端(PC的操作系统) NAS端的设置我这里仅以群晖的NAS操作系统来介绍，威联通的我没玩过，然而原理都一样。 首先你得把群晖的NAS操作系统更新到7.0版本，能够通过控制面板->更新和还原这个界面来查看： 而后，套件两头里找到SAN Manager这个套件，进行装置： 关上装置好的SAN Manager，抉择LUN，点击新增。 抉择你创立空间所用的磁盘，而后输出调配容量，我这里调配的是1T容量。这里就是从你这块磁盘划分出一块空间当做一块虚构磁盘的意思。 这里一路下一步上来，LUN就会创立好，而且SAN Manager会主动为你创立一个Target，并且把LUN和Target会绑定好关系。在iSCSI里，你就会看到曾经创立并映射好关系的Target。这里的Target是你客户端最终要连贯的指标。 而后你须要将NAS服务器的3260端口通过路由器映射进来，如果进行端口映射我这里就不说了。如果不会的请自行baidu。 至此，NAS端的设置就实现了。 Windows端的设置windows是原生反对iSCSI协定的。无需第三方软件既能够实现配置。这里我以windows 10的设置来举例。 首先win+R关上运行，输出services.msc 而后在关上的服务窗口里找到Microsoft iSCSI Initiator Service，启动它 随后在控制面板中找到管理工具，关上它 在管理工具里找到iSCSI发动程序，双击关上 在弹出的窗口中抉择发现tab页，点击发现门户 在弹出的窗口中，输出你家路由的公网IP地址(不晓得怎么申请公网的，能够看结尾的另一篇文章介绍)和端口，端口我这里映射的是33260。 如果检测通过的话，回到指标tab页，你就会看到已发现的target指标，点击连贯就能够了。 设置完这些后，你会发现，你的磁盘并没有多一块进去啊。别急，磁盘还须要做最初一步初始化动作。右击我的电脑，点治理，关上磁盘管理器。你会发现有一块磁盘还未被调配(这里我是拿一块调配了5G空间的演示) 抉择GPT分区表形式进行确定，而后进行格式化。这里磁盘格式要留神下，如果你是想在多台windows电脑进行挂载就选NTFS，如果你是想在macOS和windows之间进行独特挂载就选FAT32。 格式化结束之后，咱们能够看到。这块磁盘曾经齐全像是在本地一样了。 这时，咱们关上我的电脑，会发现多了一块磁盘，而且从外表上来看，你齐全看不出这是块iSCSI挂载的硬盘。你甚至于能够把软件和游戏装到这外面！ macOS端的设置-Initiator XMac下的iSCSI协定苹果始终以来没有集成，所以这里须要用到第三方的软件来进行挂载。 macOS下的挂载iSCSI的软件不多。而且大多数须要免费。钻研了下，macOS下有2个抉择，daemon tools和Initiator X。 ...

前言：截止到完稿为止，我依然找不出好的办法解决外网的下载问题，十分道歉集体的能力和经济无限，我也只能给你们这篇教训了，心愿能帮忙到你们。转自我的博客，原文能让你取得更好的浏览体验：原文链接注：文末有个小彩蛋NAS & 其它相干硬件的选购购买之前一些要留神的点 硬盘的读写速度 一般来说，机械硬盘的速度都是 100m/s - 500m/s 之间。通常而言，尤其是 USB 2.0 / SATA 接口的，大多都是 100m/s 左右的读写速度。 啊，如果看不懂下面讲的货色，也不要紧，总而言之，这会影响 NAS 数据存取的速度，也就是说通常而言，有线状态下（USB 3.0 / SATA 接口） 最高速只会达到 100m/s - 500m/s 也就是说，一部 10G 大小的蓝光电影，最大的速度下只须要破费20秒左右，就能转移到别的中央。 这里就要引入高速缓存盘的概念了，有一些高端 NAS 是能够加装一条 SSD（固态硬盘）作为高速缓存盘的。 什么意思呢？首先固态硬盘的读写速度通常都在 1000m/s - 3000m/s，这就意味着，固态硬盘“有线”接入电脑的状况下，最快的状况下只须要 3秒 多就能转移 10G 的蓝光电影了。 （下文还会具体阐明，此处只是进行要点揭示。） 我买的是 西部数据 4T 紫盘（监控盘，不太适宜 NAS） ￥560（实体店价格），希捷 1T 一般绿盘 ￥199。 我集体在应用的 NAS 这个截图是从中关村在线得来的， 中关村在线 。 我买的是二手，价格是￥550。 家里Wi-Fi路由器的网线口是百兆还是千兆 这点，十分十分重要，甚至比下面讲的硬盘读写速度还要重要，它间接决定，设施无线连接的时候的下载速度的快慢。 怎么查呢？到 中关村在线 输出本人设施的 品牌 - 型号，点进详细信息就能看到了，因为我的 Wi-Fi 路由器比拟老旧 / 非凡？，在中关村搜不到，最初在天极产品库中找到。 ...

咱们在帮助某AI客户排查一个UFS文件存储的性能case时发现，其应用的Pytorch训练IO性能和硬件的IO能力有很大的差距（前面内容有具体性能比照数据）。让咱们感到困惑的是： UFS文件存储，咱们应用fio自测能够达到单实例最低10Gbps带宽、IOPS也可达到2w以上。该AI客户在高IOPS要求的AI单机小模型训练场景下，或者之前应用MXNet、TensorFlow框架时，IO都能跑到UFS实践性能，甚至在大型分布式训练场景中，UFS也能够齐全胜任。 于是咱们开启了和客户的一次深度联结排查。 初步尝试优化一、调整参数：基于上述情况，首先思考是不是应用Pytorch的姿态不对？参考网上提到教训，客户调整batch_size、Dataloader等参数。 Batch_size 默认batch_size为256，依据内存和显存配置尝试更改batch_size大小，让一次读取数据更多，发现理论对效率没有晋升。通过剖析是因为batch_size设置与数据读取逻辑没有间接关系，IO始终会保留单队列与后端交互，不会升高网络交互上的整体延时（因为用的是UFS文件存储，前面会讲到为什么用）。 Pytorch Dataloader Pytorch框架dataloader的worker负责数据的读取和加载、调配。通过batch_sampler将batch数据调配给对应的worker，由worker从磁盘读取数据并加载数据到内存，dataloader从内存中读取相应batch做迭代训练。这里尝试调整了worker_num参数为CPU核数或倍数，发现晋升无限，反而内存和CPU的开销晋升了不少，整体减轻了训练设施的累赘，通过 worker加载数据时的网络开销并不会升高，与本地SSD盘差距仍然存在。 这个也不难理解，前面用strace排查的时候，看到CPU更多的时候在期待。 所以：从目前信息来看，调整Pytorch框架参数对性能简直没有影响。 二、尝试不同存储产品在客户调整参数的同时，咱们也应用了三种存储做验证，来看这里是否存在性能差别、差别到底有多大。在三种存储产品上放上同样的数据集： 单张均匀大小20KB的小图片，总量2w张。以目录树形式存到三种存储下的雷同门路，应用Pytorch罕用的规范读图接口CV2和PIL测试后果，如下图： 注：SSHFS基于X86物理机（32核/64G/480G SSD*6 raid10）搭建，网络25Gbps 论断：通过对存储性能实测， UFS文件存储较本地盘、单机SSHFS性能差距较大。 为什么会选用这两种存储（SSHFS和本地SSD）做UFS性能比照？ 以后支流存储产品的选型上分为两类：自建SSHFS/NFS或采纳第三方NAS服务（相似UFS产品），个别场景中也会将须要的数据下载到本地SSD盘做训练。传统SSD本地盘领有极低的IO延时，一个IO申请解决根本会在us级别实现，针对越小的文件，IO性能越显著。受限于单台物理机配置，无奈扩容，数据根本 “即用即弃”。而数据是否平安也只能依赖磁盘的稳定性，一旦产生故障，数据恢复难度大。然而鉴于本地盘的劣势，个别也会用作一些较小模型的训练，单次训练任务在较短时间即可实现，即便硬件故障或者数据失落导致训练中断，对业务影响通常较小。 用户通常会应用SSD物理机自建SSHFS/NFS共享文件存储，数据IO会通过以太网络，较本地盘网络上的开销从us级到ms级，但根本能够满足大部分业务需要。但用户须要在日常应用中同时保护硬件和软件的稳定性，并且单台物理机有存储下限，如果部署多节点或分布式文件系统也会导致更大运维精力投入。 咱们把后面论断放到一起看： 隐形论断：Tensorflow、Mxnet框架无问题。调整Pytorch框架参数对性能简直没有影响。3、Pytorch+UFS的场景下， UFS文件存储较本地SSD盘、单机SSHFS性能差距大。 联合以上几点信息并与用户确认后的明确论断： UFS联合非Pytorch框架应用没有性能瓶颈， Pytorch框架下用本地SSD盘没有性能瓶颈，用SSHFS性能可承受。那起因就很显著了，就是Pytorch+UFS文件存储这个组合存在IO性能问题。 深刻排查优化看到这里，大家可能会有个疑难：是不是不必UFS，用本地盘就解决了？ 答案是不行，起因是训练所需的数据总量很大，很容易超过了单机的物理介质容量，另外也出于数据安全思考，寄存单机有失落危险，而UFS是三正本的分布式存储系统，并且UFS能够提供更弹性的IO性能。 依据以上的信息疾速排查3个论断，基本上能够判断出： Pytorch在读UFS数据过程中，文件读取逻辑或者UFS存储IO耗时导致。于是咱们通过strace察看Pytorch读取数据整体流程： 通过strace发现，CV2形式读取UFS里的文件（NFSV4协定）有很屡次SEEK动作，即使是单个小文件的读取也会“分片”读取，从而导致了屡次不必要的IO读取动作，而最耗时的则是网络，从而导致整体耗时成倍增长。这也是合乎咱们的猜想。 简略介绍一下NFS协定特点： NAS所有的IO都须要通过以太网，个别局域网内延时在1ms以内。以NFS数据交互为例，通过图中能够看出，针对一次残缺的小文件IO操作将波及元数据查问、数据传输等至多5次网络交互，每次交互都会波及到client与server集群的一个TTL，其实这样的交互逻辑会存在一个问题，当单文件越小、数量越大时则延时问题将越显著，IO过程中有过多的工夫耗费在网络交互，这也是NAS类存储在小文件场景下面临的经典问题。 对于UFS的架构而言，为了达到更高扩展性、更便当的维护性、更高的容灾能力，采纳接入层、索引层和数据层的分层架构模式，一次IO申请会先通过接入层做负载平衡，client端再拜访后端UFS索引层获取到具体文件信息，最初拜访数据层获取理论文件，对于KB级别的小文件，理论在网络上的耗时比单机版NFS/SSHFS会更高。 从Pytorch框架下两种读图接口来看：CV2读取文件会“分片”进行，而PIL尽管不会“分片”读取，然而基于UFS分布式架构，一次IO会通过接入、索引、数据层，网络耗时也占比很高。咱们存储共事也理论测试过这2种办法的性能差别：通过strace发现，相比OpenCV的形式，PIL的数据读取逻辑效率绝对高一些。 优化方向一： 如何升高与UFS交互频次，从而升高整体存储网络延时CV2：对单个文件而言，“分片读取”变“一次读取”通过对Pytorch框架接口和模块的调研，如果应用 OpenCV形式读取文件能够用2个办法， cv2.imread和cv2.imdecode。 默认个别会用cv2.imread形式，读取一个文件时会产生9次lseek和11次read，而对于图片小文件来说屡次lseek和read是没有必要的。cv2.imdecode能够解决这个问题，它通过一次性将数据加载进内存，后续的图片操作须要的IO转化为内存拜访即可。 两者的在零碎调用上的对比方下图： 咱们通过应用cv2.imdecode形式替换客户默认应用的cv2.imread形式，单个文件的总操作耗时从12ms降落到6ms。然而内存无奈cache住过大的数据集，不具备任意规模数据集下的训练，然而整体读取性能还是晋升显著。应用cv2版本的benchmark对一个小数据集进行加载测试后的各场景耗时如下(提早的非线性降落是因为其中蕴含GPU计算工夫): PIL：优化dataloader元数据性能，缓存文件句柄通过PIL形式读取单张图片的形式，Pytorch解决的均匀提早为7ms(不含IO工夫)，单张图片读取(含IO和元数据耗时)均匀提早为5-6ms，此性能程度还有优化空间。 因为训练过程会进行很多个epoch的迭代，而每次迭代都会进行数据的读取，这部分操作从屡次训练任务上来看是反复的，如果在训练时由本地内存做一些缓存策略，对性能应该有晋升。但间接缓存数据在集群规模回升之后必定是不事实的，咱们初步只缓存各个训练文件的句柄信息，以升高元数据拜访开销。 咱们批改了Pytorch的dataloader实现，通过本地内存cache住训练须要应用的文件句柄，能够防止每次都尝试做open操作。测试后发现1w张图片通过100次迭代训练后发现，单次迭代的耗时曾经根本和本地SSD持平。然而当数据集过大，内存同样无奈cache住所有元数据，所以应用场景绝对无限，仍然不具备在大规模数据集下的训练伸缩性。 UFS server端元数据预加载以上client端的优化成果比拟显著，然而客户业务侧须要更改大量训练代码，最次要是client端无奈满足较大数据量的缓存，利用场景无限，咱们持续从server端优化，尽量升高整个链路上的交互频次。 失常IO申请通过负载平衡达到索引层时，会先通过索引接入server，而后到索引数据server。思考到训练场景具备目录拜访的空间局部性，咱们决定加强元数据预取的性能。通过客户申请的文件，引入该文件及相应目录下所有文件的元数据，并预取到索引接入server，后续的申请将命中缓存，从而缩小与索引数据server的交互，在IO申请达到索引层的第一步即可获取到对应元数据，从而升高从索引数据server进行查问的开销。 通过这次优化之后，元数据操作的提早较最后可能降落一倍以上，在客户端不做更改的状况下，读取小文件性能已达到本地SSD盘的50%。看来单单优化server端还是无奈满足预期，通过执行Pytorch的benchmark程序，咱们失去UFS和本地SSD盘在整个数据读取耗时。 此时很容易想到一个问题：非Pytorch框架在应用UFS做训练集存储时，为什么应用中没有遇到IO性能瓶颈？ 通过调研其余框架的逻辑发现：无论是MXNet的rec文件，Caffe的LMDB，还是TensorFlow的npy文件，都是在训练前将大量图片小文件转化为特定的数据集格局，所以应用UFS在存储网络交互更少，绝对Pytorch间接读取目录小文件的形式，防止了大部分网络上的耗时。这个区别在优化时给了咱们很大的启发，将目录树级别小文件转化成一个特定的数据集存储，在读取数据做训练时将IO施展出最大性能劣势。 优化方向二：目录级内的小文件转换为数据集，最大水平降到IO网络耗时基于其余训练框架数据集的共性功能，咱们UFS存储团队连忙动工，几天开发了针对Pytorch框架下的数据集转换工具，将小文件数据集转化为UFS大文件数据集并对各个小文件信息建设索引记录到index文件，通过index文件中索引偏移量可随机读取文件，而整个index文件在训练任务启动时一次性加载到本地内存，这样就将大量小文件场景下的频繁拜访元数据的开销齐全去除了，只剩下数据IO的开销。该工具后续也可间接利用于其余AI类客户的训练业务。 工具的应用很简略，只波及到两步： 应用UFS自研工具将Pytorch数据集以目录模式存储的小文件转化为一个大文件存储到UFS上，生成date.ufs和index.ufs。应用我方提供Folder类替换pytorch原有代码中的torchvision.datasets.ImageFolder数据加载模块（即替换数据集读取办法），从而应用UFS上的大文件进行文件的随机读取。只需更改3行代码即可。20行：新增from my_dataloader import * 205行：train_dataset = datasets.ImageFolder改为train_dataset = MyImageFolder ...

昨天重启完NAS后，明天早上发现NAS又死机了。只能再次强制关机，重启。启动docker容器之前，我把mysql容器的内存调整了一下，调整成了512M。 而后就喜剧的发现启动不了了。起初发现，启动不了不是我调内存的关系。 查看日志，显示如下: 2020-12-27T02:43:53.375776Z 0 mysqld: [Warning] World-writable config file '/etc/mysql/my.cnf' is ignored.2020-12-27T02:43:53.375776Z 0 mysqld: Error on realpath() on '/var/lib/mysql-files' (Error 2 - No such file or directory)2020-12-27T02:43:53.375776Z 0 [ERROR] [MY-010095] [Server] Failed to access directory for --secure-file-priv. Please make sure that directory exists and is accessible by MySQL Server. Supplied value : /var/lib/mysql-files2020-12-27T02:43:53.376005Z 0 [ERROR] [MY-010119] [Server] Aborting百度了下，解决办法是从新run一个mysql容器，并且在之前的配置上加上-v /mnt/md0/User/wzp/home/www/mysql-files:/var/lib/mysql-files/。 当初问题来了，之前run mysql容器时，我并没有记录下残缺的run 命令。还好，通过rekcod工具能够查看。更喜的是，这个工具能够通过docker来运行。因为我的NAS的零碎不是发行版的linux，npm，yum好多工具都没法装置。 对于rekcod的应用能够参考linuxea:如何复现查看docker run参数命令 简略来说，用法如下： ...

目标：在172.16.20.19上配置nfs服务，共享/data2目录，将其挂载至172.16.20.11和172.16.20.12的/data2 一、服务端1.装置nfs-utils、rpcbindyum install -y nfs-utils rpcbindsystemctl enable nfs-serversystemctl enable rpcbindsystemctl start nfs-serversystemctl start rpcbind2.配置目录echo "/data2 172.16.20.*(rw,sync,no_root_squash)" >> /etc/exportsexportfs -r #重载失效howmount -e #查看确认二、客户端172.16.20.11和172.16.20.12别离执行以下操作 1.装置nfs-utilsyum install -y nfs-utils2.挂载showmount -e 172.16.20.19 #确认通信mkdir /data2 #创立挂载目录mount -t nfs 172.16.20.19:/data2 /data23. 增加开机挂载echo "172.16.20.19:/data2 /data2 nfs defaults 0 0" >>/etc/fstab

把斐讯 N1 重装了 Armbian 零碎，这里记录 设置 WIFI 步骤。 <!--more--> 步骤更新 /etc/network/interface 文件 备份 interface : cd /etc/network && cp interface interface.bak更新 interface:# armbian-config createdsource /etc/network/interfaces.d/*# Local loopbackauto loiface lo inet loopbackauto eth0allow-hotplug eth0iface eth0 inet dhcpallow-hotplug wlan0iface wlan0 inet manualwpa-roam /etc/wpa_supplicant/wpa_supplicant.confiface default inet dhcp更新 /etc/wpa_supplicant/wpa_supplicant.conf 备份 wpa 配置文件： cd /etc/wpa_supplicant/ && cp wpa_supplicant.conf wpa_supplicant.conf.bak更新 wpa_supplicant.conf：network={ ssid="网络 ID" psk="明码"}重启网络， ping 百度试下是否连通， 失常应该能够胜利连网。参考Arbian 配置 WifiN1 盒子刷 Armbian

1.若是Windows用户，请先在电脑上安装支持SSH访问的工具，如putty。安装完成后，请为你的TNAS开启SSH访问。2.前往控制面板-网络服务-Telnet与SNMP；3.选择允许SSH访问，系统默认端口为9222，你也可以自行设置，点击应用；4.开启成功能，在电脑上运行putty；5.在Host name栏输入TNAS的IP地址，在Port栏输入9222或你设置的端口号，点击Open；6.点击是，在弹出的Putty框中输入用户名root，按回车键；7.输入TOS系统的管理员密码，按回车键，系统提示Welcome to TNAS，现在，你可以输入命令从后台访问TNAS。8.若你是Mac用户需要通过SSH访问TNAS，请点击前往-应用程序-实用工具；9.在实用工具列表中选择终端，进入命令页面；10.输入ssh -p端口号root@服务器IP地址，按回车键；系统提示Welcome to TNAS，现在，你可以输入命令从后台访问TNAS。

通过TOS应用中心的邮件服务器功能，你可以将TNAS 架设成你自己的邮件服务器。邮件服务器是管理邮件数据库和邮件账户的工具。1.控制面板-应用中心，安装邮件服务器、MySQL数据库；2.点击桌面MySQL服务器，打开MySQL数据库，并将MySQL服务器启用；3.打开邮件服务器；4.勾选“启用电子邮件服务器”，选择存储路径，密码必须与Mysql服务器一致，点击应用；5.选择域名列表，创建域名；6.填写域名、描述，点击应用（可以根据需求设置邮箱的数量和容量限制）；7.选择邮箱列表，创建邮箱；8.填写邮箱信息，点击应用；9.设置完成。注意：如需在外网收发邮件，需要有固定的IP地址和邮件域名。

当TNAS 配置有两个或者两个以上的网络接口时，您可以为网络接口创建“Bond” 。通过创建“Bond” ，您可以为不同的网络接口设定分工，以便使网络接口工作效率最大化。1.前往TOS桌面-控制面板-网络服务；2.网络设置-网络接口；3.点击创建Bond，从列表中选择合适的Bond模式，点击下一步；4.勾选要加入Bond的网口，点击下一步；5.为Bond设置一个未被占用的IP地址，点击应用；6.创建完成。

系统怕受到外界的破坏，如病毒，程序损坏等，造成开不了机，数据无法恢复。在这之前如果进行了备份，等于买了保险一样，出故障只需简单还原便可。说真话，我以前从来没用过这个傲梅备份，也就听说过非常方便好用。今天终于得以见到庐山真面目了。第一步应用中心下载、安装轻松备份软件（4.1系统）打开傲梅备份，选择你要备份的盘符，如我就选择了系统C盘。第二步就是备份到铁马威F4-421 NAS，这里需手动输入固定地址。选择复制到哪个具体的目录。备份过程中我分时间段查看了进度，C盘36GB左右，备份只花了20分钟，做到了备份安全又快捷。备份完后系统也仔细检查了这个镜像文件是有效且数据完整的。

通过K8S使用NAS卷，请区分以下场景： 静态存储卷： 使用阿里云ACK，PV、PVC方式，nfs驱动；使用阿里云ACK，PV、PVC方式，Flexvolume驱动；使用阿里云ACK，Volume方式，nfs驱动；使用阿里云ACK，Volume方式，Flexvolume驱动；自建K8S，PV、PVC方式，nfs驱动；自建K8S，Volume方式，nfs驱动；动态存储卷： 使用阿里云ACK使用自建K8S静态卷-使用阿里云Kubernetes(ACK)时1. 使用PV、PVC方式（nfs驱动）首先确认当前的挂载是否配置了noresvport参数，参考NAS团队提供的方式； 例如当前的pv如下面yaml： apiVersion: v1kind: PersistentVolumemetadata: name: pv-nasspec: accessModes: - ReadWriteOnce capacity: storage: 2Gi mountOptions: - vers=3 nfs: path: /default server: 2564f49129-ggu23.cn-shenzhen.nas.aliyuncs.com persistentVolumeReclaimPolicy: Retain编辑PV： kubectl edit pv pv-nas更新mountOptions：mountOptions: - vers=4.0 - noresvport或者： mountOptions: - vers=3 - nolock,tcp,noresvport重启使用这个pv的pod； 需要注意： 由于一个节点上，如果已经有某个挂载点挂载在一个目录下了，其他的挂载(相同挂载点)即使配置了noresvport参数，还是会follow以前的挂载参数。即noresvport不生效；解决方法：方法1：修改pv参数后，把所有使用这个挂载点的pod掉离这个节点，然后再调回来。方法2：使用新的挂载点创建新的pv使用（一个nas文件系统可以有2个挂载点）； 示例方法1： 集群中有2个worker节点，部署一个deploy包含3个Pod；# kubectl get node | grep -v masterNAME STATUS ROLES AGE VERSIONcn-shenzhen.i-wz9c9m0m4oldr6mt89rd Ready <none> 55d v1.12.6-aliyun.1cn-shenzhen.i-wz9gvy73m4qyk03xzg1y Ready <none> 60d v1.12.6-aliyun.1# kubectl get podNAME READY STATUS RESTARTS AGEnas-static-784496fbb9-cqr97 1/1 Running 0 63mnas-static-784496fbb9-gljbq 1/1 Running 0 63mnas-static-784496fbb9-ngzkq 1/1 Running 0 63m编辑pv，添加- nolock,tcp,noresvport Options；编辑deploy，把这个deploy的pod都调度到节点：cn-shenzhen.i-wz9c9m0m4oldr6mt89rd上；> 在deploy中添加 nodeName: cn-shenzhen.i-wz9c9m0m4oldr6mt89rd> 如果您的集群节点较多，可以给一批节点添加label，然后通过nodeSelector把pod调度到这写节点；> 参考：https://kubernetes.io/zh/docs/tasks/configure-pod-container/assign-pods-nodes/注意：如果您用的时候statefulset的应用，需要把updateStrategy.type配置为RollingUpdate；然后再把pod调度到其他节点：cn-shenzhen.i-wz9gvy73m4qyk03xzg1y到节点cn-shenzhen.i-wz9gvy73m4qyk03xzg1y 上验证noresport，已经生效。2564f49129-ggu23.cn-shenzhen.nas.aliyuncs.com:/default on /var/lib/kubelet/pods/aa79e380-9bdb-11e9-a545-00163e0eff42/volumes/kubernetes.io~nfs/pv-nas type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,nolock,noresvport,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.0.11,mountvers=3,mountport=4002,mountproto=tcp,local_lock=all,addr=192.168.0.11)最后，由于当前使用nas的pod是有nodeName标签的，可以编辑deploy，把nodeName(nodeSelector)去掉。2. 使用PV、PVC方式（Flexvolume驱动）首先确认当前的挂载是否配置了noresvport参数，参考NAS团队提供的方式； ...

十多年来，NAS中已经存在的目录和文件达到10亿之多，在设计和开发备份系统的过程中碰到了很多挑战，本文将分享大量文件名记录的树形结构存储实践。 一、引言既然是定期备份，肯定会有1次以上的备份。对于一个特定目录，每次备份时都要与上次备份时进行比较，以期找出哪些文件被删除了，又新增了哪些文件，这就需要每次备份时把该目录下的所有文件名进行保存。我们首先想到的是把所有文件名用特定字符进行拼接后保存。由于我们使用了MySQL保存这些信息，当目录下文件很多时，这种拼接的方式很可能超出MySQL的Blob长度限制。根据经验，当一个目录有大量文件时，这些文件的名称往往是程序生成的，有一定规律的，而且开头一般是重复的，于是我们想到了使用一种树形结构来进行存储。 例如，一个有abc、abc1、ad、cde 4个文件的目录对应的树如图1所示。 图1 树形结构示例 图1中，R表示根节点，青色节点我们称为结束节点，从R到每个结束节点的路径都表示一个文件名。可以在树中查找是否含有某个文件名、遍历树中所有的文件名、对树序列化进行保存、由序列化结果反序列化重新生成树。 二、涉及的数据结构注意：我们使用java编写，文中涉及语言特性相关的知识点都是指java。 2.1 Node的结构包括根节点在内的每个节点都使用Node类来表示。代码如下： class Node { private char value; private Node[]children = new Node[0]; private byte end = 0; }字段说明： value：该节点表示的字符，当Node表示根节点时，value无值。children：该节点的所有子节点，初始化为长度为0的数组。end：标记节点是否是结束节点。0不是；1是。叶子节点肯定是结束节点。默认非结束节点。2.2 Node的操作 public Node(char v); public Node findChild(char v); public Node addChild(char v);操作说明： Node：构造方法。将参数v赋值给this.value。findChild：查找children中是否含有value为v的子节点。有则返回子节点，没有则返回null。addChild：首先查找children中是否已经含有value为v的子节点，如果有则直接将查到的子节点返回；否则创建value为v的节点，将children的长度延长1，将新创建的节点作为children的最后一个元素，并返回新创建的节点。2.3 Tree的结构 class Tree { public Node root = new Node(); }字段说明：Tree只含有root Node。如前所述，root的value无值，end为0。初始时的children长度为0。 2.4 Tree的操作 public void addName(String name) ; public boolean contain(String name); public Found next(Found found); public void writeTo(OutputStream out); public static Tree readFrom(InputStream in);操作说明： ...

无法删除的文件最近部门NAS测试团队遇到一个非常诡异的问题，在删除一棵存在SMB共享文件夹的文件树时，删除完子目录的所有文件后，再删除这个子目录的时候居然系统报出“Directory Not Empty”的错误从而导致用例测试未通过，打开这个目录一看，确实有一个文件并未删除成功，再查看I/O工具的日志，报告所有的文件都已经成功删除。难道是I/O工具出了问题而没有正确报出错误，这个经过工具开发者的研究后确认后貌似工具没有任何问题，这个问题起初被开发团队踢皮球，死活不承认是SMB2服务器的问题。死活非得让抓取网络包来证实。 作为一个网络分析的伪专家，自己也厚着脸皮主动蹭入NAS测试团队强行出力，希望把这个悬案搞个谁落石出。 抓包重现首先，设置好抓包参数，同时重现问题，这一步很顺利。由于测试参数没有任何更改，很顺利的重现了问题，并且将出问题对应时间点的网络包悉数抓到。 在Windows2106的客户端开启抓包工具wireshark(其对应的命令行工具为 tshark), 并且设置好相关参数: $ tshark -i ens1 -B 4096 -s 1024 -w client-traffic.pcap参数的含义就是在接口ens1上抓取长度为1024字节的每一个帧， 并把这些帧存在client-traffic.pcap的文件里 分析在抓取到网络包以后，我们开始解包分析： 同样通过tshark命令解包分析, 并将揭开的内容分别重定向到摘要文件client-traffic.summary和详细展开格式的client-traffic.detail文件当中： $ tshark -t ud -Y "ip.addr==<server-ip>" -r client-traffic.pcap >>client-traffic.summary$ tshark -t ud -O smb2 -Y "ip.addr==<server-ip>" -r client-traffic.pcap >>client-traffic.detail打开client-traffic.summary文件后的一步就是要找到对应未删除成功的文件(文件名: VCg8iMkGWgll2VJoEFMUa0FKp1DJHEG2)最后一次出现的帧，简单的通过文本搜索便可定位，找到对应的帧以后发现，这个操作是一个Create操作，根据协议[MS-SMB2], 删除操作是通过一组三元操作 Create/SetInfo/Close来实现的，称为Delete-On-Close，由于我们正要寻找的是删除操作，借此可以大胆推测，这个Create (Frame #210725)请求正是三元删除重的第一步, 再往后的帧一个个寻找，果然找到了第二步SetInfo (Frame #210727) 和第三步Close (Frame #210757, 通过该帧展开后确认其FileID属性与前两步操作对象一致) 两个请求以及对应的服务器端的回复:最后Close并未得到服务器回复 Delete-On-Close 操作中的前两步Delete-On-Close 操作中的前两步然而最后的一步的close 请求(Frame #210757)并未得到服务器端的回复，那么问题显然出在了这里，继续往下分析，为什么服务器没有对最后一步close操作作出响应呢？ 最后Close并未得到服务器回复 奇怪的是，这个close操作发出后在0.1秒内没有得到任何回复，于是出发了TCP层的超时重传(RTO)(Frame #210765)，按道理说在同一个实验室的内部网络下，网络状况是十分好的，基本上不可能发生RTO的情况(即便连快速重传也是极为罕见的)，除非服务器出现了宕机。此时我突然想到我们测试当中为了测试SMB2的CA功能(Continues Availability：高可靠性，容忍服务器重启或者故障转移), 经常会引入错误注入的测试用例，再次翻看测试日志，果然发现在创建和删除文件操作的同时有重启服务器节点的操作执行，查看时间戳和发生问题的时间点一直，现在基本可以明确的是，发生的问题和CA有关了。 删除文件同时服务器重启 现在来看看正常的CA流程，当客户端一个SMB2请求遇到服务器重启的情况下，网络会暂时断开，发出的请求在若干次超时重传以后会收到服务重启后发出的TCP重置请求(RST)(Frame #210769), 客户端在收到此请求后便可得知网络发生了断连，为是后续操作得以延续，必须再次建立TCP的连接(通过三次握手 Frame #210770, #210771, #210772), 重新协商(Negotiate. Frame #210773)建立会话(Session Setup. Frame #210776)和共享文件根目录的连接(Tree Connect. Frame #210785), 最后，因为客户端知道在网络断连之前最后一次没有响应的操作即目标文件，此时客户端会通过Create操作(Frame #210787)重新发起一个对目标文件的连接(在client-traffic.detail可看到展开后的Create操作的RECONNECT信息)，从而接续上服务器从其前的步骤，实现CA的功能特性 ...

采集k8s挂载Nas后的日志该文档主要介绍使用logtail以两种不同的方式进行k8s挂载Nas后的日志采集。两种采集方式的实现原理是一样的，都是通过将Logtail和业务容器挂载到相同的NAS上，使Logtail和业务容器的日志数据共享，以此实现日志采集。下面是两种采集方式的各自特点：1. SideCar模式。比较灵活、适合水平扩容，适用于数据量较大的场景；2. 单独部署Logtail的Deployment。资源消耗比较低、但灵活性以及伸缩性不强，适用于整体集群数据量较少的场景（建议整体日志量不超过每秒10M）。1. Sidecar NAS采集方式通过 链接 使用PV&PVC的方式配置挂载Nas的nas-pvc步骤一 创建pv步骤二 创建pvc步骤三 根据下面的yaml模板创建含有logtail的Pod，进行单个Pod的内部采集sideCar模式实验yaml内容：apiVersion: batch/v1kind: Jobmetadata: name: nginx-log-sidecar1-demospec: template: metadata: name: nginx-log-sidecar-demo spec: # volumes配置 volumes: - name: nginx-log persistentVolumeClaim: claimName: nas-pvc containers: # 主容器配置 - name: nginx-log-demo image: registry.cn-hangzhou.aliyuncs.com/log-service/docker-log-test:latest command: ["/bin/mock_log"] args: ["–log-type=nginx", “–stdout=false”, “–stderr=true”, “–path=/var/log/nginx/access.log”, “–total-count=1000000000”, “–logs-per-sec=100”] volumeMounts: - name: nginx-log mountPath: /var/log/nginx # Logtail的Sidecar容器配置 - name: logtail image: registry.cn-hangzhou.aliyuncs.com/log-service/logtail:latest env: # user id - name: “ALIYUN_LOGTAIL_USER_ID” value: “${your_aliyun_user_id}” # user defined id - name: “ALIYUN_LOGTAIL_USER_DEFINED_ID” value: “${your_machine_group_user_defined_id}” # config file path in logtail’s container - name: “ALIYUN_LOGTAIL_CONFIG” value: “/etc/ilogtail/conf/${your_region_config}/ilogtail_config.json” # env tags config - name: “ALIYUN_LOG_ENV_TAGS” value: “pod_name|pod_ip|namespace|node_name|node_ip” - name: “pod_name” valueFrom: fieldRef: fieldPath: metadata.name - name: “pod_ip” valueFrom: fieldRef: fieldPath: status.podIP - name: “namespace” valueFrom: fieldRef: fieldPath: metadata.namespace - name: “node_name” valueFrom: fieldRef: fieldPath: spec.nodeName - name: “node_ip” valueFrom: fieldRef: fieldPath: status.hostIP # 和主容器共享volume volumeMounts: - name: nginx-log mountPath: /var/log/nginx # 健康检查 livenessProbe: exec: command: - /etc/init.d/ilogtaild - status initialDelaySeconds: 30 periodSeconds: 30 restartPolicy: “Never"SLS控制台采集配置设置如下图：日志路径与被采集容器的日志所在路径一致注意：由于NAS路径已经挂载到了Logtail容器上，所以不需要打开docker文件的按钮采集上来的系统默认字段含义：source: pod容器内部IP__tag__:hostname: pod名称__tag__:path: 日志路径__tag__:receive_time: 采集时间__tag__:user_defined_id: 用户自定义标识__tag__:namespace: pod所属namaspace__tag__:node_ip: pod所在Node的IP地址__tag__:node_name: pod所属Node的name__tag__:pod_ip: pod容器内部IP__tag__:pod_name: pod名称用户参数：2. 一个Logtail采集所有POD的NAS数据注意项：副本数spec.replicas只能为1，不能更多，多了会重复采集。首先，创建一个logtail的deployment，以下是本次使用的模板:apiVersion: apps/v1kind: Deploymentmetadata: name: logtail-deployment namespace: kube-system labels: k8s-app: nas-logtail-collecterspec: replicas: 1 selector: matchLabels: k8s-app : nas-logtail-collecter template: metadata: name: logtail-deployment labels: k8s-app : nas-logtail-collecter spec: containers: # Logtail的配置 - name: logtail image: registry.cn-hangzhou.aliyuncs.com/log-service/logtail:latest env: # aliuid - name: “ALIYUN_LOGTAIL_USER_ID” value: “${your_aliyun_user_id}” # user defined id - name: “ALIYUN_LOGTAIL_USER_DEFINED_ID” value: “${your_machine_group_user_defined_id}” # config file path in logtail’s container - name: “ALIYUN_LOGTAIL_CONFIG” value: “/etc/ilogtail/conf/${your_region_config}/ilogtail_config.json” volumeMounts: - name: nginx-log mountPath: /var/log/nginx # volumes配置 volumes: - name: nginx-log persistentVolumeClaim: claimName: pvc-test-nginx__注意：__这里的 claimName: pvc-test-nginx 以及mountPath: /var/log/nginx 是将logtail的/var/log/nginx挂载了Nas下的/nginx文件夹相关参数设置请参考方案1中的表格说明logtail运行成功之后，可以在SLS控制台根据模板中的ALIYUN_LOGTAIL_USER_DEFINED_ID创建对应的机器组，请参考方案1中的表格说明。这里新建2个Pod来测试采集是否成功，其中一个POD的模板为:apiVersion: v1kind: Podmetadata: name: “test-nginx-2"spec: containers: - name: “nginx-log-demo” image: “registry.cn-hangzhou.aliyuncs.com/log-service/docker-log-test:latest” command: ["/bin/mock_log”] args: [”–log-type=nginx", “–stdout=false”, “–stderr=true”, “–path=/var/log/nginx/access.log”, “–total-count=1000000000”, “–logs-per-sec=100”] volumeMounts: - name: “nas2” mountPath: “/var/log/nginx” volumes: - name: “nas2” flexVolume: driver: “alicloud/nas” options: server: “Nas挂载地址” path: “/nginx/test2” vers: “4.0"另一个Pod将 /var/log/nginx 挂载在了 /nginx/test1 目录下；结合logtail的挂载情况，现在两个Pod分别挂载在 /nginx/test1 和 /nginx/test2，而logtail挂载在了 /nginx 下。最后配置logtail的采集配置因为logtail也挂载了相同的Nas，所以logtail只需要采集自身文件夹下的日志就可以了，这里的是否为docker文件选项关闭。注意：由于NAS路径已经挂载到了Logtail容器上，所以不需要打开docker文件的按钮本文作者：元乙阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

介绍：本文介绍的动态生成NAS存储卷的方案：在一个已有文件系统上，自动生成一个目录，这个目录定义为目标存储卷；镜像地址：registry.cn-hangzhou.aliyuncs.com/acs/alicloud-nas-controller:v1.11.5.4-433631d-aliyun默认生成资源：生成的PV名字为：pvc-${pvc-uid}生成目录的名字：namespace-pvcname-pvname可以再pvc的annotations中如下声明，自定义名字：生成的pv、目录名字为下面定义的名字。 annotations: pv-name-created: replace-user-id2. 部署NAS Controller创建alicloud-nas-controller，实现动态provider nas pv；创建alicloud-nas storageclass，为nas pv provision 提供模板；apiVersion: storage.k8s.io/v1kind: StorageClassmetadata: name: alicloud-nasprovisioner: alicloud/nasreclaimPolicy: Deleteparameters: drivertype: flexvolume nfsversion: “4.0” options: “”—kind: DeploymentapiVersion: extensions/v1beta1metadata: name: alicloud-nas-controller namespace: kube-systemspec: replicas: 1 strategy: type: Recreate template: metadata: labels: app: alicloud-nas-controller spec: tolerations: - effect: NoSchedule operator: Exists key: node-role.kubernetes.io/master - effect: NoSchedule operator: Exists key: node.cloudprovider.kubernetes.io/uninitialized serviceAccount: admin containers: - name: alicloud-nas-controller image: registry.cn-hangzhou.aliyuncs.com/acs/alicloud-nas-controller:v1.11.5.4-433631d-aliyun imagePullPolicy: Always volumeMounts: - mountPath: /persistentvolumes name: nfs-client-root env: - name: NFS_SERVER value: 154154b095-.cn-beijing.nas.aliyuncs.com - name: NFS_PATH value: / volumes: - name: nfs-client-root flexVolume: driver: alicloud/nas options: path: / server: 154154b095-.cn-beijing.nas.aliyuncs.com vers: “4.0"StorageClass使用说明：drivertype: 用来表示生成pv存储类型，可选nfs, flexvolume. nfs: 默认选项，表示使用k8s原生NFS驱动挂载； flexvolume: 表示使用阿里云提供的Flexvolume NAS驱动挂载；nfsversion: 挂载nfs使用的版本，支持3，4.0.默认为4.0； drivertype为flexvolume的时候在这里配置； 为nfs的时候通过mountOptions 配置；options：为挂载nfs的可选项配置； drivertype为flexvolume的时候在这里配置； 为nfs的时候通过mountOptions 配置；StorageClass举例：## 使用kubernetes提供的NFS驱动，并配置mountOptions，reclaimPolicy为Delete；apiVersion: storage.k8s.io/v1kind: StorageClassmetadata: name: alicloud-nas-nfsmountOptions:- vers=4.0- noresvportprovisioner: alicloud/nasreclaimPolicy: Delete## 使用阿里云提供的Flexvolume NAS驱动，配置nfs版本、options；apiVersion: storage.k8s.io/v1kind: StorageClassmetadata: name: alicloud-nas-flexprovisioner: alicloud/nasreclaimPolicy: Deleteparameters: drivertype: flexvolume nfsversion: “3” options: “noresvport"3. 创建应用-Deployment：kind: PersistentVolumeClaimapiVersion: v1metadata: name: replace-user-id annotations: pv-name-created: replace-user-idspec: storageClassName: alicloud-nas accessModes: - ReadWriteMany resources: requests: storage: 5Gi—apiVersion: extensions/v1beta1kind: Deploymentmetadata: name: “deploy-nas"spec: replicas: 1 strategy: type: Recreate template: metadata: labels: app: deploy-nas spec: containers: - name: “nginx” image: “nginx” volumeMounts: - name: pvc-nas mountPath: “/data” volumes: - name: pvc-nas persistentVolumeClaim: claimName: replace-user-id执行：# userID=“hello-123”# cat deploy.yaml | sed “s/replace-user-id/"$userID"/g” | kubectl create -f -# kubectl get pod | grep deploy-nasdeploy-nas-85696b6bfc-t5dmh 1/1 Running 0 28m# kubectl get pvc | grep hellhello-123 Bound hello-123 5Gi RWX alicloud-nas-flex 28m# kubectl get pv | grep hellhello-123 5Gi RWX Delete Bound default/hello-123 alicloud-nas-flex 28m# Nas目录下查看生成目录：# ls -l | grep hellodrwxrwxrwx 2 root root 4096 2月 19 09:58 hello-1234. 创建应用-StatefulSet：使用volumeTemplateClaim不支持使用pv-name-created配置pv名字；apiVersion: v1kind: Servicemetadata: name: nginx labels: app: nginxspec: ports: - port: 80 name: web clusterIP: None selector: app: nginx—apiVersion: apps/v1beta1kind: StatefulSetmetadata: name: webspec: replicas: 2 serviceName: “nginx” template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:alpine volumeMounts: - mountPath: “/data” name: pvc-sts volumeClaimTemplates: - metadata: name: pvc-sts spec: accessModes: - ReadWriteOnce storageClassName: alicloud-nas-flex resources: requests: storage: 2Gi 创建后查看：# kubectl get pod | grep webweb-0 1/1 Running 0 7sweb-1 1/1 Running 0 4s# kubectl get pvc | grep webpvc-sts-web-0 Bound pvc-65ab251a-33ec-11e9-a151-00163e066784 2Gi RWO alicloud-nas-flex 13mpvc-sts-web-1 Bound pvc-8437c50e-33ed-11e9-a151-00163e066784 2Gi RWO alicloud-nas-flex 5m# kubectl get pv | grep webpvc-65ab251a-33ec-11e9-a151-00163e066784 2Gi RWO Delete Bound default/pvc-sts-web-0 alicloud-nas-flex 13mpvc-8437c50e-33ed-11e9-a151-00163e066784 2Gi RWO Delete Bound default/pvc-sts-web-1 alicloud-nas-flex 5m# Nas目录下查看生成目录：# ls -l | grep stsdrwxrwxrwx 2 root root 4096 2月 19 10:16 default-pvc-sts-web-0-pvc-65ab251a-33ec-11e9-a151-00163e066784drwxrwxrwx 2 root root 4096 2月 19 10:24 default-pvc-sts-web-1-pvc-8437c50e-33ed-11e9-a151-00163e0667845. 创建应用-Pod：kind: PersistentVolumeClaimapiVersion: v1metadata: name: replace-user-id annotations: pv-name-created: replace-user-idspec: storageClassName: alicloud-nas-flex accessModes: - ReadWriteMany resources: requests: storage: 5Gi—apiVersion: v1kind: Podmetadata: name: “nas-pod"spec: containers: - name: “nginx” image: “nginx” volumeMounts: - name: pvc-nas mountPath: “/data” volumes: - name: pvc-nas persistentVolumeClaim: claimName: replace-user-id # userID=“pod-123”# cat pod.yaml | sed “s/replace-user-id/"$userID"/g” | kubectl create -f -# kubectl get pod | grep podnas-pod 1/1 Running 0 32s# kubectl get pvc | grep podpod-123 Bound pod-123 5Gi RWX alicloud-nas-flex 44s# kubectl get pv | grep podpod-123 5Gi RWX Delete Bound default/pod-123 alicloud-nas-flex 48s# ls -l | grep poddrwxrwxrwx 2 root root 4096 2月 19 10:54 pod-123本文作者：kanjunbao阅读原文本文为云栖社区原创内容，未经允许不得转载。

为了做个NAS，折腾了超久的Samba，看似简单，其实Samba的用户设置实在太繁琐，坑太深。用户权限和目录权限、甚至磁盘格式稍有不同，都会导致无法登录。实在不靠谱，实际体验也不是很稳定。所以在找Alternatives过程中，发现了这个也存在了很久的WebDav协议。不像Samba是一个微软开发的软件体系，WebDav只是一种协议，确切说是世界上最普遍的HTTP协议的一个小扩展。它不是一个软件。所以就好理解，为什么搜索不到WebDav的官网和官方安装指南了——因为没有“官方”。谁都可以开发软件支持这个协议，就像水都可以开发浏览器支持HTTP协议浏览网站一样。参考：How To Set Up WebDAV With Apache2 On Debian Etch# 安装Apache2服务器sudo apt-get install -y apache2# 开启Apache2中对WebDav协议的支持 (记住最好在用户目录下执行否则报错)cd ~sudo a2enmod davsudo a2enmod dav_fs# 创建共享目录并修改权限sudo mkdir -p /var/www/webdavsudo chown -R www-data:www-data /var/www/webdav# 创建WebDav的访问用户数据库，顺便创建用户pisudo htpasswd -c /etc/apache2/webdav.password pi# 创建guest用户#sudo htpasswd /etc/apache2/webdav.password guest# 修改用户数据库访问权限sudo chown root:www-data /etc/apache2/webdav.passwordsudo chmod 640 /etc/apache2/webdav.password# 打开默认配置文件sudo vim /etc/apache2/sites-available/000-default.conf# 全部替换为以下内容（记得先备份）：Alias /webdav /var/www/webdav<Location /webdav> Options Indexes DAV On AuthType Basic AuthName “webdav” AuthUserFile /etc/apache2/webdav.password Require valid-user </Location># 重启Apache2服务器sudo systemctl restart apache2# 或sudo /etc/init.d/apache2 reload然后就可以用任意浏览器输入：http://树莓派的IP地址/webdav来访问了。注意，webdav后面没有/斜杠。网页中如果正常显示目录中的文件结构，则可以正常访问：这一步完成，我们就可以开始把这个共享文件夹映射到Mac、Windows上的本地文件夹了。磁盘映射网页里只能像FTP一样显示文件目录和下载文件。如果要正常使用，我们需要把它映射为本地目录才行：Mac上：在Finder中用CMD+K打开连接服务器选项，输入http://树莓派IP地址/webdav，输入Webdav创建过的用户名密码来完成映射。iPhone上：安装网盘访问最强的Readdle Documents，添加WebDav服务，输入信息后就可以访问。直接看文档、看视频、听歌都行。Windows上：比较麻烦的是，Win7以上默认只支持HTTPS的网络驱动器，做为HTTP的WebDav是不能连的。所以要修改Windows注册表，让它支持HTTP。方法入下：开始菜单 -> 运行 -> 输入regedit 并按回车，就打开了注册表注册表中找到HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters\BasicAuthLevel这个项目，把值改为2。开始菜单 -> 运行 -> 输入cmd 并按回车，打开命令行输入net stop webclient并按回车，停止网络客户端输入net start webclient并按回车，开启网络客户端然后在文件夹菜单中找到映射网络驱动器，输入网址http://树莓派IP地址/webdav或\树莓派IP地址\webdav，然后输入用户名密码，就能映射成功了。浏览器上：随便什么设备，只要是个浏览器就能支持。可以在线播放常用视频，直接打开图片浏览。但是不能上传。挂载外部磁盘（移动硬盘、U盘）和Samba一样，只要在/var/www/webdav/这个共享出来的文件夹中，创建个空目录，然后把移动硬盘用mount命令挂载到这个目录上。外部就可以访问了。使用速度和感受配置上，比Samba不知道简单到哪里去了。实验证明，速度非凡！Mac映射完成后，访问就像本地文件夹一样快，而且可以直接看视频、预览图片、支持原本各种快捷键等。还可以直接拖放文件来复制，速度也快到和本地复制文件没有区别。如果对比Samba，最明显的是看图片和视频的打开速度。Samba要等一秒以上，而WebDav几乎没有等待，或者说和本地打开文件一样速度。唯一缺点是，Windows访问的话，是很卡很卡的。稳定性上，因为是基于Apache2的，bug非常少，权限也不用傻傻分不清（和本地用户也没关系）。远程访问上（我在AWS新加坡服务器上建的WebDav），速度也相当可靠，比我访问树莓派的WebDav还快。毕竟亚马逊服务器配置高网速快。只是视频访问就没那么方便，经常卡顿、发生异常。但是也比较满意了。总结：WebDav配置方便，访问轻松，权限管理轻松，稳定，超多平台支持，完美！常见问题Apache2 Reload出错用命令sudo /etc/init.d/apache2 reload重启服务器没有反应，用命令sudo /etc/init.d/apache2 reload重新加载Apache2时也报错：[….] Reloading apache2 configuration (via systemctl): apache2.serviceJob for apache2.service failed. See ‘systemctl status apache2.service’ and ‘journalctl -xn’ for details. failed!一般来讲，很有可能是80端口被占用了，有可能是Nginx。所以要找到占用端口的服务，并关闭它。具体方法如下：# 找到所有nginx相关进程$ ps -ef |grep nginx# 按照显示出的nginx进程号逐一关闭$ sudo kill -TERM 进程号# 或$ pkill -9 nginx# 重新加载Apache2服务器$ sudo /etc/init.d/apache2 reload# 重启Apache2服务器$ sudo systemctl restart apache2Reload后成功后就会显示：这样再用浏览器尝试访问webdav服务的网址，就OK了为什么访问WebDav很慢一般来讲，无论是WebDav还是Samba，访问速度慢主要有这些因素：服务器网速不够本机客户端电脑的网速不够路由器速度有限服务器硬盘（或U盘）配置太低（转速低）服务器主机电脑配置低：CPU、内存都不足 （树莓派就是这样）客户端所在的电脑配置低所以，如果以上所有原因都不构成连接速度慢的原因的话，才需要考虑是不是WebDav软件设置和架构出了问题。 ...

终于有点时间来解决下家中NAS需求了。一般自制NAS，只有选Samba。速度比FTP快，便利性比Windows文件夹共享好，设置多等等。▶参考：samba简介安装Samba$ sudo apt-get update$ sudo apt-get install samba samba-common-bin核心步骤：配置SambaSamba唯一设置的入口就算一个smb.conf文件，所有变化都依次而来，出了问题也只需要在这里找原因。配置之前先说明，这里我不打算只共享一个文件夹，而是共享树莓派连接上的所有外置硬盘。树莓派的外置硬盘默认挂载在了/media/pi目录下，每个硬盘挂载为/media/pi/drive1，/media/pi/drive2等。所以不用一个一个共享，直接把/media/pi共享就OK了。下面配置还会限制：只有pi这个用户可以访问。常用且肯定没问题的最简单配置如下：# 编辑Samba的配置文件sudo vim /etc/samba/smb.conf# 文件末尾添加这个共享文件夹的定义：[NAS]comment = NAS External drivepath = /media/pipublic = Yesbrowseable = Yeswriteable = Yesvalid users=pi其中：valid users：只允许指定的用户和用户组访问设置Samba用户名和密码这一步也至关重要，直接影响各设备的访问。注意，这个用户必须是本机已经在group和user里面都存在的用户，且必须权限设置什么的符合samba要求才行。否则会导致有些设备完全无法访问这个文件夹。之前试了自己groupadd和useradd本地用户后，又在samba里smbpasswd -a添加用户名密码，结果Mac完全访问不了，Windows也是根据系统的不同有的能访问有的不能访问。所以这里推荐用树莓派的默认用户名pi：# 输入Samba用户的访问密码sudo smbpasswd -a pi重启Samba# 推荐重启方法（可以看到自检过程）$ sudo /etc/init.d/samba restart到这一步，如果没出问题的话，就会显示成功：按照之前的配置，现在你就可以访问Samba共享文件夹了。访问方法一般访问方法如下：Windows：直接打开桌面的网络（网上邻居）-> RaspberryPi(树莓派的网络名)，然后就可以看到树莓派上所有共享的文件夹和设备了。Mac: 稍微麻烦一点，在Finder中点击菜单 -> Go -> Connect to server -> 输入smb://IP地址，按照要求输入本机或树莓派的Samba用户名密码：然后可以看到，目录中和本地目录几乎没什么区别：能看预览，支持所有文件夹正常的快捷键，随意拷贝粘贴，这是FTP远不能比的。将Samba的共享目录映射到本地Windows上，直接在文件夹里点击菜单->工具->映射网络驱动器。然后选择映射出来的驱动盘字母，点击浏览，选择网络邻居里的树莓派，确定完成。就会在本地的计算机里显示出映射磁盘了。Mac上，一般在文件夹里面通过Cmd+K连接服务器后打开共享文件夹后，系统就会自动把它挂载到/Volumes/你的共享文件夹名这里。可以直接通过命令行随意访问。然后即使桌面上的文件夹关闭后，也还是可以在命令行里正常访问。多用户访问Samba我们用Samba，就肯定有多用户需求。但是多用户问题恰是Samba最麻烦的地方，如果是像我这样对Linux用户权限不熟悉的话。首先需要明了：Samba的里面添加的用户，必须是Linux已经存在的用户！而且这个用户必须有相应的权限，才行。所以多用户策略大概如下：创建Linux本机用户组，并赋予相应权限创建Linux本机的用户，并赋予相应权限创建共享文件夹，修改文件夹权限，修改文件夹所有者，改为对应的Samba用户或用户组创建与Linux用户对应的Samba用户，并创建密码在Samba配置文件里面，声明有权访问共享文件夹的用户或用户组注意：挂载的NTFS磁盘，是不支持unix体系的group和user的，所以里面的文件默认所有者和所属组都是root。要解决这个，需要在mount挂载时就指定所有者，但是也不能分别指定里面某个文件夹或目录的所有者。Samba调试Samba的自检程序testparm自动测试，并显示Samba所有的共享和定义：$ testparm列出当前所有已注册的Samba用户$ sudo pdbedit -L使用smbclient测试smbclinet是命令行客户端，需要下载安装使用：# 安装$ sudo apt-get install smbclient# 连接Samba服务器$ smbclient //192.168.1.111/share -U sambaUser01$ smb: ls如果连接成功，就会进入smb的交互shell，然后输入ls，成功列出目录，则连接完全成功。这是常用的最方便的测试方法，如果有任何一点不成功，这个连接命令都无法执行。只要这里能够正常访问，那么其它地方都没有问题。常见问题Mac上能用guest访问却不能用设置了的用户访问这个是你的Samba用户设置出了问题。有可能是Samba中定义的用户，在本机中权限不够。解决方法就是：直接用树莓派的原生用户pi，或仔细研究新创建的用户权限，添加好了再到Samba配置中设置原生用户pi以外的用户都不能访问外置磁盘尝试过多用户方案，只要不是外置磁盘，都能正常访问、读写。但是插的U盘，外置移动硬盘，除了pi用户以外全都只能进入，不能写入。就算把新建用户升级到超级用户，就算把文件目录的所有者改为新建的用户，也还是一样的。消除来自Mac的.DS_Store文件安全隐患Mac上访问远程文件夹会留下.DS_Store文件，其中包含太多信息这样很不安全。所以我们要在Mac上设置，在访问远程文件夹时不留下这个文件：$ defaults write com.apple.desktopservices DSDontWriteNetworkStores true但是以上方法不是完全生效，目前MacOS 10.12以上都不一定能生效。访问外置硬盘Permission Denied这个也是用户权限问题，配置原生pi用户就没问题了。