Frank1940

Problem is that this spec on the drive lists the running power draw. It does not specify what the startup (inrush) current draw is when the platters are being spun up. This can range as high as 3 amperes— very old number from many years ago. (I don't know what modern drives' startup current but a rule of thumb is to figure 2 amperes and you will never be wrong. You also have to use this number when sizing the power supply because Unraid spins up all of its drives simultaneous during is normal operation– one reason why PS with a single +12V rail are recommended. One must realize that modern PS will shutdown if the max current rating is exceeded after a few milliseconds.)

What I did was share (export) a 'disk' out via SMB and set the permission on that Disk Share to R/W. I then used Windows File Explorer to create a fold at the root of the share. Now, I had a User Share on the Unraid side of the house. Opened up the Share Settings for that Share and made all of the required settings. (Of course, I then turned off the Disk Share since my use of it was finished.)

A bit of Background: https://forums.unraid.net/topic/119052-psa-on-sandisk-usbs/ The problem is that there are a lot of counterfeit drives out there. San disk is just one of the more prominent but Samsung would be another likely target! And the cheaper no-name manufacturers don't even brother with adding a GUID onto their product. There are rumors that Unraid version 7.3.X may have an alternative licensing scheme. Best advice is buy from a reputable vendor (Amazon is NOT one of those for several reasons that have to do with their warehousing model) and don't buy on price alone.

GEt the diagnostics file and post it up in a new post in this thread. (Click on diagnostics for instructions.)

Yes. This is a disadvantage to large-capacity parity and data disks. Any parity operation will take approximately 2 hours per TB.

Many versions of Windows 11 no longer allow guest connections to any server. (I suspect this restriction was added at the bequest of big business to prevent their road warriors, after a few rounds of cocktails, from visiting servers looking for pron and getting much more than that!)

Start with this post and the next two posts: https://forums.unraid.net/topic/191221-some-musings-on-smb-and-samba-and-unraid-and-windows/#findComment-1561581

I won't argue with your logic but let me point out that most of the plugins in the current APP store have been developed by Unraid users working on their own time and then offered to the community for free. Imagine if paid developers were doing all of this work how that would impact on the cost of a license! There have been plugins that have moved from being Plugins to being a part of the core Unraid release. Two that come to mind are the UPS module and the File Manager. Plus, let me point out that a feature like Custom Share SMB plugin has a very limited usage group. I showed how to do it from the command line back in April of 2023 and have had only five 'likes'. The Plugin was first posted up in December of 2025 and, while if has not yet made it into the APP store, it has gotten even fewer likes.

Not True! See here for a plugin to do exactly that: https://forums.unraid.net/topic/195826-plugin-custom-smb-shares/

If you follow the rules for MS security it generally works without issue. See this thread for those and why: https://forums.unraid.net/topic/191221-some-musings-on-smb-and-samba-and-unraid-and-windows/ You can not always have things work the way that you want them to. You should be setting things up so that they work the way that the people who have control of the system want you to use it. Screwing around with group policy editor or registry editor in an attempt to fix things to work the way you want can result in problems in the future. I understand that Apple OS's have SMB issues but there again Apple has their own way of doing things and MS and Apple don't have a great track record of cooperating with each other./ Granted that the Unraid server may not always show up under the 'Network' in Windows File Explorer but there is a workaround for this. (And this is not strictly an Unraid problem. I also have the same issue with my Windows peer-to-peer client/server computers!)

You actuality have this post in the wrong thread! This has been a problem for a long time. I don''t have any MS Accounts or logins at my choice but I understand that many of them contain '@" as the login is a email address. I have seen it recommended that Unraid users not use that Windows login (Which I understand Windows will try in its sequence to gain access to a server..) for this reason but use a different name and password in a Windows Credential.. EDIT: I did test this and there is logic to black adding a user which does not meet these requirements. Please remember that even though you may be using this user to access the array or pool via SMB, you are actually adding a user at the Linux level— not via SMB. You can access your shares via NFS using the same login credentials. A lot of these requirements go back to the origins of UNIX when the input/output devices were Teletype machines and those developers were not trained typists so they minimized all typing to an absolute minimum! . (Think of how people text message today!!!!)

Posted request in in new section of Forum for Feature Requests... https://product.unraid.net/p/fix-logic-on-add-share-tab

@MHzTweaker, The AI summary from Google search: Remember that AI is not always 100% right but I know the first one is a factor that most people are completely unaware of.

That is actually good protectlion all by its self. That container is often used as shipping container by just slapping a label on it.

I don't remember. I know that there is a nice status/results page that is a part of Unassigned Devices Preclear plugin. There is also a Support Thread that you can reach from the PLUGIN Tab of the GUI if you have further questions. (Or they might be already answered int he thread.)

In the olden days, A lot of us use to run about three full preclear cycles on any new hard disk. BUT, disk size was about the 3TB max size range. The object was to put about 100 hours of intensive disk activity on any disk before committing to use in the array. But you also have to remember that back then disk reliability is not what it is today. DOA disk and infant-mortality were bigger issues than they seem to be today. With your description of how this disk was packed, I would do enough preclear cycles to put a minimum of a hundred hours on it. My last 12TB drive took about 46 hours for one cycle. (Hopefully, your vendor has a 30 day exchange policy.) PS— I have two spare drives on the shelf because I kinda saw this price boast coming with Trump's tariff promise...

I made a recent feature request. What is going to happen to it?

Start here and then the next two posts: https://forums.unraid.net/topic/191221-some-musings-on-smb-and-samba-and-unraid-and-windows/#findComment-1561581

This is probably your biggest problem. You can put the drive inside the case to make it less accessible. Plus, a decent case will have provisions for putting locks on it to make entry more difficult. Security camera would be another option. You should make sure that the flash/boot drive is not being exported. That way it can not be accessed via file sharing. Here are the permissions on the flash/boot from Linux: Have secure password (15 semi-random characters minimum) for root/GUI/console access. As you can see, only root has access to it from Linux. You should disable Telnet and enable SSH only if you need remote access via that route. (As I recall, you can use Tailscale to access the GUI which would probably be preferable to SSH.) All security is relative. Any scheme can be compromised. You just have to make it a difficult as possible.

Two things— First, determine the time required to stop the Array using the button on the MAIN tab. Then make sure that this setting is long enough to allow for the array to be stopped. Second. Think about your UPS for a minute. Realize that it has enough energy stored to run your server fro twenty minutes to, perhaps, an hour. It will take a minimum of eight hours to recharge that battery if you run it to almost fully discharge. Now, think about your power interruptions. In my area, we have two kinds of interruptions. One is the power company maintenance ones. They last less than ten seconds. Then there are all the other types. They last for a couple of hours at a minimum. I have set my UPS to only run thirty seconds on battery before requesting that the server be shut down. Remember that the "Time on battery before shutdown (seconds):" parameter only starts the shutdown. It can take several minutes after that you actually get your server shutdown cleanly. (Part of this time is flushing all the cached writes from RAM onto the physical media where it is safe.) I f you are like most of us, after power restoration, you want to get the server back on-line ASAP. Remember that the battery is now partially discharged and it will be several hours before recovery to a fully charged state. You want it to have enough reserve to be able to handle a second outage.

See here: https://forums.unraid.net/topic/197301-fix-logic-on-add-share-tab/

One more thought— Is there a logic scan of the a share with an illegal character in the share name which the user is attempting to modify the share to use a ZFS pool to prevent such a change from being made? (From a support standpoint, it is a vital consideration!!!)

It has come to my attention that there are now additional restrictions on the allowed characters in the Share Name in version 7.2.3. (Apparently, these were added to accommodate restrictions imposed by the ZFS file system scheme.) This was first brought to light in this thread: https://forums.unraid.net/topic/197271-unraid-723-share-names-cant-use-spaces-or-any-special-characters/ I have tested the add share feature and discovered a couple of facts. First, I try to simply add a share with an illegal character, I can not do it. See below: But if I use a bit of slight of hand and create a share by adding a folder/directory at the root of a drive, I can add a share with an illegal character. See below: I verified that I could do all the things required in the share settings that one would expect. I exported, made it Private, assigned user permissions, changed the storage method to make Array secondary store and the single Cache drive primary, etc. Then using the Share, I created folders/directories via SMB, copied files to it, deleted files, ect. Everything worked! The only thing that did not work was to be able to generate the share itself if it had one of the currently defined illegal characters in it. Here is what I am requesting: Change the logic on the ADD Share to allow creating a share with an illegal character if a ZFS component is not involved. (Leave the cautionary note. Change the Help files to indicate exactly why the restrictions on the characters is required and fro what services. REASONING FOR REQUEST: I have no intention at this point of ever using ZFS! (Reason explained in the referenced thread.) I would assume that there are a lot of Unraid users who are of the same mind. Why should we be punished for a restriction imposed by the ZFS system? (And, why, one may ask, have the ZFS developers allowed such a restriction on naming to even exist in the day and age. This takes me back to DOS3.11 and CPM days!)

If I don't set an option that requires the usage of a ZFS restricted setting, why should I not be allowed to make it? That would seem to be the most user-friendly implementation of this restriction. I don't see any reason to even consider using ZFS on either of my server. (And I don't believe that 'bit-rot' can occur on modern hard disks— the data is there as originally written on the disk or it will either (1) correct it or (2) throw an error ...)

The logic of this is correct but it falls apart when one considers that there may be thousands of Unraid users who already have shares that contain illegal characters. If they modify that share to use a ZFS pool what happens????? The logic in this Tab must be able to accommodate this. Perhaps it should just issue a warning if the share name contains one of the illegal characters but does not use a ZFS pool. In the case where it uses a ZFS and the share name contains a illegal character, then it should refuse to complete the operation. This would cover both the Share creation process and the Share modification process.