John_M

It tells the samba server to deny the file's existence. See here: https://www.samba.org/samba/docs/using_samba/ch08.html That's fine if your Windows computers are connecting via SMB and your Macs are connecting via AFP, but with modern versions of OS X SMB is being used more and more, so the Macs are also being denied access to the ._ files. The hide option is a much better one in that case.

The problem is when an OS X (or is it macOS now?) user comes onto the shares, the Windows users see those ._ files and .DS_Store files anyway and it is super annoying when it clutters it up. And anyway, DS_Store files are there to speed up Spotlight searches (I believe) and does no harm when deleted. It just means that server-side files won't get indexed, which is a enhancement, because it improves security. The DS in .DS_Store stands for Desktop Services and have nothing to do with Spotlight indexing. The files contain information about the enclosing folder, such as icon size and layout, scroll-bar position, window background, etc. All these are irrelevant to Windows users but they are used by the OS X Finder to keep its view on the folder consistent. They provide part of the look and feel of the system so I, for one, would not care to lose them. The ._ files are described above and they are also where extended attributes are stored. Again, as a mostly Mac user, I wouldn't want to lose them. You can hide all "hidden" dot-files from Windows users.

Since you are an OS X user, why do you want to remove (or, rather, prevent the creation of) these files? They actually do serve a purpose with OS X and you can hide them, along with all other .* files, if they clutter up any Windows Explorer windows. If you do suppress their creation then you are not copying every aspect of the original file, which seems like a bad thing to me. If by default they weren't created I would be making a feature request to enable them.

Probably means 9TB total array size, based on the duration I'm guessing parity disk is 3TB. Hmmm... His sig suggests otherwise...

@loggers1234 I'm curious to know how (and why) you achieve 9 TB of parity?

Well, the OP asked for some data points, specifically wanting to see how his own figures compare, so I don't feel that I'm bragging. I posted a good parity check speed (135 MB/s, average) because I'm using modern disks that are all the same capacity. They are 5 TB Toshibas that cost me around £100 each, which is somewhat less than the equivalent capacity Seagates, WDs and HGSTs. The rest of my hardware is by no means high end. For the record it's an Asus A88XM-A motherboard, again fairly modern but by no means expensive, and a modest but effective A6-6400K APU. I have four disks (including the two parities) controlled by the motherboard and four controlled by an AOC-SASLP-MV8, which is now rather old but not over-stretched. I have more memory than I need (16 GiB), but it's cheap, so why not? I run Plex, Krusader and MakeMKV as Dockers and I have a single simple Linux VM, with IOMMU switched off and no attempts at passing through hardware. So it's nothing like the dual Xeon set-ups with 10 Gb/s NICs I see several of the recent adopters of unRAID are using, and frankly, struggling with, going by their posts to the 6.2.0-beta threads. In fact, my most expensive single component is the power supply - a good investment, IMO. Overall, I'm very pleased to get respectable performance without a huge expenditure.

The figure I quoted is the average, as displayed by Dynamix and stored in the History.

I get 135 MB/s on a server with two parity disks and six data disks. The disks are all the same size and type: Toshiba MD04ACA500, 5 TB.

That's great. Many thanks. In Mac OS X a folder with a custom icon contains a file that has a control character in its name. It's system-generated and can't be changed and it can only be avoided by ensuring that all folders use the generic icon. This caused problems with the Dynamix file integrity plugin and required a specific exclusion. See here: http://lime-technology.com/forum/index.php?topic=44989.msg436925#msg436925

That's OK. Thanks for replying. As you say, it's a warning, not an error - I can ignore it. There are three other warnings and two error messages that I ignore too. They're all related to my not having auto-updates enabled - I simply don't like things auto-updating and I'm happy to take the responsibility for manually updating. I would prefer it if they were all warnings, rather than two ("Plugin Update Check not enabled" and "This plugin (Fix Common Problems) not set to auto update") being errors, but again, I can ignore them.

Should this be considered to be a false positive? EDIT: I should add that the SMART drive database updater plugin is one of bonienl's and it first appeared here: https://lime-technology.com/forum/index.php?topic=47875.msg461469#msg461469. I'm using it with both unRAID 6.1.9 and 6.2.0-beta21.

I think that perhaps the idea of some limitation or requirement that your VMs have to install into a share stems from the fact that many people install them onto their cache disks. Any folder in the root of the cache is by definition a user share. Some people install them onto separate disks that operate outside of the main unRAID array and cache, and to do that they make use of Unassigned Devices to manage those disks. In addition to providing an easy way of automatically mounting disks outside the main array, UD makes it easy to share them across the network but that, as far as I can see, is a bonus, not a necessity for using them to hold VMs.

Yes there is a workaround and that is to mount it manually in the go file like below. #Mount the intel 750 nvme mkdir /mnt/nvme mount /dev/nvme0n1 /mnt/nvme You also have to partition and format it if you haven't already done that. More info in this post by dAigo But this still doesn't let me create share on it, meaning VMs cannot be run off from it. Forgive my ignorance, but why do you feel the need to create a share for your VMs to install into? Wouldn't a simple folder do the job? Isn't this the requirement/limitation of unraid? Well, I only use a couple of very simple VMs, myself and I don't try to do anything clever like passing through hardware devices, so your requirements may be very different from mine. But I see no intrinsic requirement for the folder that contains the virtual disk images (or any installation ISOs, for that matter) to be accessible across a network, which, after all, is the purpose of a share. Suppose you follow saarg's suggestion and then mkdir /mnt/nvme/VMs and set up your VMs to have their disk images there. Wouldn't that achieve what you're wanting to do? I can see a case for making the location of the installation ISOs available across the network, simply for the ease of copying them into place, but on the one hand they can be copied from elsewhere using the command line and on the other I doubt that you'd want to waste your expensive and fast M.2 storage on them anyway. Come to think of it, I don't even know why we're even discussing this here - it has very little to do with Unassigned Devices, other than it's something that exists outside of the main unRAID array. If I happen to be way off track, then please educate me.

Yes there is a workaround and that is to mount it manually in the go file like below. #Mount the intel 750 nvme mkdir /mnt/nvme mount /dev/nvme0n1 /mnt/nvme You also have to partition and format it if you haven't already done that. More info in this post by dAigo But this still doesn't let me create share on it, meaning VMs cannot be run off from it. Forgive my ignorance, but why do you feel the need to create a share for your VMs to install into? Wouldn't a simple folder do the job?

There is no specific place the docker image has to be. Within the system share is merely a default location. Not a required or even suggested location. My docker.ing has always been stored in the root of the cache. That option does not select to back up the image file or not. Rather it excludes it if it's in appdata. I guess I can make that clearer within the settings / manual But we both agree that it is pointless to back it up anyways Sent from my LG-D852 using Tapatalk Ah! Understood.

As Myk says, but I've known it to disappear after some update or other. Uninstalling it then re-installing it fixed the problem.

This appdata backup feature is very nice. I agree that there isn't a lot of point in backing up the docker.img file but I thought I'd try it anyway! It didn't work, though - presumably because it didn't find my docker.img file. Is it expecting to find it within the appdata folder? With the 6.2.0-betas there's a specific place where the docker.img file is expected to be by default, namely /mnt/cache/system/docker/docker.img (see Tom's post under the heading Automatic system shares). That's where mine is. Previously, with 6.1.x, its location was /mnt/cache/docker.img so I've never actually kept it inside the appdata folder.

Tools -> File Integrity. Then check the box for the disk you want to verify and click the Check button. That will check the disk against a previously exported checksum file. I'm not aware of a simple way of forcing the checking of a disk against the checksums stored in extended attributes without resorting to the command line or fiddling with the crontab.

This is what you should be seeing: Except that normally you would expect Rose also to be a candidate for election to local master, in case Elsie1 goes off-line for some reason. In other words, I would set Local master browser to Yes on both servers. Doing so simply makes them both available, without forcing either. Perhaps "Local master browser candidate" would be a less confusing name. You have an excellent point. However, there can be reasons why you might not want a particular server to be a candidate. First one is that (and in my case) Server Rose is my test bed. It shutdown down rather regularly. It gets rebooted a couple of times a week. From that standpoint, it almost as bad as the Windows clients that are on the network. Second thing to consider is how many servers does a network contain. The more servers that you make eligible, the more likely that that a new server will be elected periodically. I have always noticed that SMB networks are much more stable when the same Local Master is always assigned for each Workgroup. If that server goes down, then one can activate easily another server to serve as the Local Master if the primary server can not be restored quickly. (There are ways to influence the election but it requires some planning and some knowledge of how SMB is implemented.) Before I had a permanent Local Master on my SMB network, it was always a crap shoot as to whether I could find all of the SMB connected devices on any given day. I was sure you must have a good reason for not including that sever. Thanks for the explanation. It makes good sense.

I didn't know that! I thought moderators and admins were the only ones who can make changes. I make the occasional edit on Wikipedia so if the procedure is similar this is something I'll definitely investigate.

This is what you should be seeing: Except that normally you would expect Rose also to be a candidate for election to local master, in case Elsie1 goes off-line for some reason. In other words, I would set Local master browser to Yes on both servers. Doing so simply makes them both available, without forcing either. Perhaps "Local master browser candidate" would be a less confusing name.

When I first started with unRAID I made a point of searching out the wiki, reading about hardware compatibility, and generally researching the subject only to find that a lot of the information is out of date. There are articles that show up in searches that are no longer relevant. I'm old and have a certain amount of patience when required to read information for myself but it's frustrating to put in that effort and then discover that the information has been superseded. I know for a fact that certain members of a younger generation have far less patience than me. Perhaps a worthwhile project would be to mark as deprecated those threads that are no longer relevant. Of course, the fact that people here are so helpful also tends to make others lazy! Most questions, however dumb, get a reply - mostly the same day, often within an hour or so, sometimes within minutes. I'd say this board is a victim of its own success, and that's not such a bad place to be.

I'm still getting syslog entries like these: Apr 24 06:00:14 Lapulapu bunker: Verify task for disk2 started, total files size 3.40 TB Apr 24 11:44:27 Lapulapu bunker: warning: BLAKE2 hash key mismatch (updated), /mnt/disk2/L_Public/.AppleDB/db_errlog was modified Apr 24 11:44:27 Lapulapu bunker: warning: BLAKE2 hash key mismatch (updated), /mnt/disk2/L_Public/.AppleDB/log.0000000001 was modified Apr 24 11:44:27 Lapulapu bunker: warning: BLAKE2 hash key mismatch (updated), /mnt/disk2/L_Public/.AppleDB/cnid2.db was modified Apr 24 11:44:27 Lapulapu bunker: Verify task for disk2 finished, duration: 5 hr, 44 min, 26 sec. Apr 24 11:44:27 Lapulapu bunker: verified 2082 files from /mnt/disk2. Found: 3 mismatches (updated), 0 corruptions. Duration: 05:44:26. Average speed: 164 MB/s despite having excluded Apple metadata and starting with a fresh database by having first run rm -rf /mnt/user/L_Public/.AppleDB to remove the database, then connecting a Macintosh client via AFP and allowing it to recreate the .AppleDB folder and contents. Does the exclusion of Apple metadata actually exclude the three files listed? EDIT: I looked back to this post earlier in the thread and ran the command again: root@Lapulapu:~# ps -ef | grep inotify root 16813 1 0 Apr12 ? 00:00:00 inotifywait -dsrqo /var/run/hash.pipe -e close_write --exclude '' --format %w%f /mnt/disk1 /mnt/disk2 /mnt/disk6 root 17207 17175 0 14:13 pts/6 00:00:00 grep inotify root@Lapulapu:~# which shows no exclusions: --exclude '' So I went back to Settings and unchecked then rechecked the Apple metadata exclusion box and ran the command again: root@Lapulapu:~# ps -ef | grep inotify root 17899 1 0 14:15 ? 00:00:00 inotifywait -dsrqo /var/run/hash.pipe -e close_write --exclude ^/mnt/disk[0-9]+/(.*\.icns$|.*\.AppleDB/|.*\.DS_Store$) --format %w%f /mnt/disk1 /mnt/disk2 /mnt/disk6 root 18102 17175 0 14:15 pts/6 00:00:00 grep inotify root@Lapulapu:~# showing that the exclusions had been reset: --exclude ^/mnt/disk[0-9]+/(.*\.icns$|.*\.AppleDB/|.*\.DS_Store$) I guess the settings had been lost during recent plugin updates, though I always follow the instructions to re-apply the settings after an update of this plugin. I usually do this by toggling off the Send notifications option, then toggling it back on and clicking Apply, but I suppose that hasn't always been enough. EDIT2: I thought I'd better check my other main server: root@Northolt:~# ps -ef | grep inotify root 28977 28922 0 14:43 pts/0 00:00:00 grep inotify root 40726 1 0 Apr09 ? 00:00:00 inotifywait -dsrqo /var/run/hash.pipe -e close_write --exclude ^/mnt/disk[0-9]+/(.*\.icns$|.*\.AppleDB/|.*\.DS_Store$) --format %w%f /mnt/disk1 /mnt/disk2 /mnt/disk3 root@Northolt:~# where the settings have obviously stuck. The only software difference is that Northolt is running 6.1.9 (plus) and Lapulapu is running 6.2.0beta21 (pro).

I used to read comp.os.minix articles last millennium from the command line using the tin newsreader and I'm quite disturbed by what Usenet has become and how people now pay a subscription for the privilege of downloading pirated material in high definition automatically. I now understand why people insist on redacting their diagnostics before posting here. It's an aspect of home NAS usage I find quite distasteful. On the other hand, I've been trying to crack RC5 ciphers for years and for fun, mostly via the distributed.net project, and first with CPUs and then with GPUs. There's nothing sinister about that at all and the 72-bit version is proving to be extremely difficult to crack by brute force alone. I can't help the OP, I'm afraid, because I use AMD GPUs with other OS distributions, but I thought his comments deserved some support. My unRAID servers are just used to store my lifetime's accumulated documents, photographs, music and video, every single file either created by me or else paid for and legitimate, with the original stored away and available as proof.

Look in the syslog.