John_M

You have a name conflict. What name did you give to your Plex server? Is it the same as your unRAID server? Try changing it to Zack-Plex instead?

If one is powered down for maintenance or otherwise I'd like one of the others to take over. The same reason that people have multiple DNS servers. To be honest, it's more of an academic interest than anything. I'm not even a big Windows user - my everyday computer is a Mac which uses mDNS/Bonjour/Avahi to seek out other hosts on the network.

I notice that the stats area at the top right hand corner of the GUI never gets beyond saying Loading... nowadays. Does the link need to be updated?

That's interesting to know. I opened the SMB Settings page on three unRAID servers to try that and discovered something interesting. This shows three browser pages (one for each server) open simultaneously and screen grabbed all in one go. Any idea why each one believes it has won the election? From a Windows 10 Command prompt I typed nbtstat -a LAPULAPU > masters nbtstat -a NORTHOLT >> masters nbtstat -a OPON >> masters and here's what the masters file contains (edited to remove the irrelevant interfaces): Ethernet: Node IpAddress: [172.26.147.77] Scope Id: [] NetBIOS Remote Machine Name Table Name Type Status --------------------------------------------- LAPULAPU <00> UNIQUE Registered LAPULAPU <03> UNIQUE Registered LAPULAPU <20> UNIQUE Registered __MSBROWSE__ <01> GROUP Registered WORKGROUP <00> GROUP Registered WORKGROUP <1D> UNIQUE Registered WORKGROUP <1E> GROUP Registered Ethernet: Node IpAddress: [172.26.147.77] Scope Id: [] NetBIOS Remote Machine Name Table Name Type Status --------------------------------------------- NORTHOLT <00> UNIQUE Registered NORTHOLT <03> UNIQUE Registered NORTHOLT <20> UNIQUE Registered __MSBROWSE__ <01> GROUP Registered WORKGROUP <00> GROUP Registered WORKGROUP <1D> UNIQUE Registered WORKGROUP <1E> GROUP Registered Ethernet: Node IpAddress: [172.26.147.77] Scope Id: [] NetBIOS Remote Machine Name Table Name Type Status --------------------------------------------- OPON <00> UNIQUE Registered OPON <03> UNIQUE Registered OPON <20> UNIQUE Registered __MSBROWSE__ <01> GROUP Registered WORKGROUP <00> GROUP Registered WORKGROUP <1D> UNIQUE Registered WORKGROUP <1E> GROUP Registered So which one is actually in charge?

I don't think you can force a particular host to be a local master - the best you can do is include your preferred candidate in the election. It's that way by design.

Thanks. I thought I'd ask because it seems so obvious and repeatable that I thought it might just be a "feature". I'd file a bug report if I could. I'm getting a 404 error at the moment though - already mentioned in the "Welcome to unraid.net" thread.

I've had a number of unclean shutdowns recently in which my server rebooted during heavy disk I/O. I've traced the problem to a failing HBA and I've replaced it and now I'm in the process of restoring lost data from backups. It made one disk "Unmountable: unsupported partition layout". The effects of a failing HBA can be quite catastrophic. After a spontaneous reboot the Main page indicates that an unclean shutdown has occurred and starting the array will begin a parity check. That's all as expected. However, I notice that if instead of starting the array, I either do a manual reboot or power down in order to investigate the hardware and power up again later, the unclean shutdown message isn't displayed and starting the array doesn't force a parity check. I wondered if anyone else had noticed this and whether it's a quirk, a bug or something else? Running a correcting parity check manually found and fixed 1500 or so errors. A subsequent parity check found zero errors, as expected. This is unRAID 6.5.3.

Settings -> Network Settings

The recent update to Dynamix System Stats displays the memory usage graph incorrectly, giving a negative value to Used. Is there a reason why the top of the graph has never coincided with the amount of RAM installed? This particular server has 8 GB but the graph extends to 10 GB, which, of course, can never be reached.

What was the outcome?

This is he only thread I could find that mentions Aquantia NICs:

That's great news. Thanks for confirming it. It depends on how much damage there is. Thanks for trying that technique. Shame it didn't work. The loss will be minimal though. The only file affected is likely to be the one that was being written at the time of the corruption. Don't ignore Disk 1 though. Make sure you have notifications enabled.

Probably a power glitch during a write. So either total loss of power (unsafe shutdown while a write is in progress) or a power cable/splitter or PSU problem.

Here's @johnnie.black's post: It so happens that in that case it was Disk 6 that was corrupt too, so the command will work for you as they are. Are you able to follow it? If you're unsure about anything, please ask.

Normally the advice would be yes but there's something that disk expert johnnie.black recommended recently. Are you ok with the Linux command line? Basically, the plan is to try to mount the disk somewhere safe outside of the array so tat it can sort out its journal, then unmount it and run xfs_repair again. If that doesn't work then use the -L option as a last resort.

You have two separate problems. Disk 6 has a corrupt file system so start the array in Maintenance mode and open Disk 6's page by clicking on the text "Disk 6" on the Main page. Scroll down to Check File System Status. Remove the "-n" and start the repair. Disk 1 has some SMART errors and looks as though it's beginning to fail. You can acknowledge the errors in the Dashboard by clicking on the "!". I'd run an Extended SMART test and be prepared to replace the disk.

In that case update it to the most recent release, which fixes the PHP issues.

First of all, you should have started your own thread as your situation is different from that of the OP. Have you tried the various other suggestions in the video?

It was actually complaining every eight minutes. Toggling Use SSL to Off (click Apply) and back to Auto (click Apply) seems to have stopped the messages.

Thanks for confirming that, in theory at least, it works. Sorry that it's not a practical solution though. Maybe this approach would be worth trying instead:

Did your previous server software meet your needs? There must be some reason for you to make the change to unRAID and invest a lot of effort into copying that many files over. This surprises me a little. If I were in your place I would have been asking these questions in advance, in order to find out if unRAID is really suited to my needs. It seems like you jumped early and are now looking for a kludge to make it work - believe me, that's what my suggestion is. It might well be that another solution would be better for you, so it's a shame we didn't have this discussion before you committed.

The root filesystem is unpacked into RAM each time unRAID boots so any manual changes you make to files such as /etc/passwd or /etc/group will be lost on a re-boot. You can add users via the GUI and, naturally, such changes do survive a re-boot. However, there's no GUI option to add groups, as you've discovered. The permissions on files within user shares are very lax in unRAID - typically 777 - but that will work in your favour (assuming my suggestion proves to be viable) in that your set of users (x, y, z) will not be refused access on the grounds of permissions. I'm not sure why you have 68 shares when, by my reckoning, you only need one per user (around 15, you said) plus the one you've called TEST.

I would check the viability of my suggestion before loading any more data. It might not work at all and there might not be a workable solution, in which case you will have wasted your effort. Try it on a small set of users and files, like the example you give in your OP. If it works then yes, it will take a lot of effort. What protocol are you planning to use? If NFS it would be worth checking to see if it can handle group permissions - you certainly can't do it if you're using SMB or AFP - but even if so you'd need to edit the /etc/group file manually. My use of NFS is very simplistic so I can't say for sure.

The actual files would only be present in the subfolders of the TEST user share, which would not be accessible directly, or accessible only by the administrator user - you.

Not duplicate files, just symlinks. So /mnt/user/x would contain folders symlinks to folders A -> /mnt/user/TEST/A B -> /mnt/user/TEST/B C -> /mnt/user/TEST/C And /mnt/user/y would contain folders symlinks to folders B -> /mnt/user/TEST/B C -> /mnt/user/TEST/C And /mnt/user/z would contain folder symlink to folder A -> /mnt/user/TEST/A