Frank1940

The GURUs are going to need to see your diagnostics file. Post it up in a new post in this thread. (Do NOT edit your original post to add it!!!!)

What are these two passwords for? You should only use one password for your apple client computer to log into your Unraid server for file access (SMB). (I probably should avoid answering your query as I have zero experience with the Apple environment...)

You shouljd be able to do that using the 'Edit' from the dropdown menu. IF you require greater access to the files of the container, you should use the 'console' choice from the dropdown mennu. (See the screenshot above in this thread.) You have to realize that any Docker container is an totally independent OS from Unraid. Some Containers use the storage space on the Unraid server just as you do when you save a file via a user share. You do expect that you will have unrestricted access to the files of all the user share users on your server, do you? You are not intended to access any files in the appdata share via Unraid!!! If/when you do you are hacking the container!

'nobody' is a very special user that was required by the Linux kernel many, many years ago. google nobody linux user The reason is the the appdata share is intended to be used by Docker Containers and, perhaps, some VM's. As a result, any files in that share should never by accessed by an Unraid user. It is the location where the configuration variables are stored and any files that are only used by the container. Thus the owners, groups and permissions for the files/directories are set for use by the container. If you run the new permissions tool against that share, you may break some containers! No. The solution is to get support from the Docker Container support thread to assist you to configure their container so that it works with Unraid. Unfortunately, there are a lot of apps shown in the APPS plugin that are not well supported. The ones mark 'Official" or "Limetech" are generally properly configured to work with Unraid. If you don't find one so designated, then look at all of the apps offered and try and find one that has a active support group to use.

I am not the best expert for Docker Containers. But f you left-click (#1 in the figure) on container's icon, you will see the drop-down menu. then click on #2 and see where the support thread is and take a look at it. If it is on the Unraid User Forum, you are part way home. You need to check to see how well it is supported. Even if support is minimal, you can still ask your questions there about fixing this issue. Most containers are configurable using the 'Edit' tab in the figure below. You can add new configuration variables but you have know the exact name and spelling. Yes, run the 'New Permissions' tool in the TOOLS menu. Be sure to read the instructions and cautions about not running it on certain shares!!!!!!! You want to run it only on those shares which have the problem. Note that this will only fix the problems that currently exist. If you run the container again, you will probably have to run the tool again afterwards. Unraid sets and expects the permissions to be 777 (directories) and 666 (files) that it writes using Samba and NFS (Linux). Group will always be "users" but the owner is often the name of the Share User. (Some folks have told me that 'nobody' sometimes is assigned as 'owner'. I know that Samba can be set up to force the 'owner' to be a specific user name. So I am always careful not to say that this is the way things are absolutely. I don't pretend to be a SAMB/SMB expert. I do understand a fair amount about how it works and I can only share that info.)

umask is a bit of a difficult thing to wrap your head around. See here for one result of a google search: https://www.geeksforgeeks.org/linux-unix/umask-command-in-linux-with-examples/ Basically, umask of 022 turns off the write bit for 'group' and 'other'. Unraid does not want you to do that! With today's Unraid default security access mode, access for most users will be through the 'group' permissions. Particuliarily if you are using the 'Secure' or ;Prinvate' security modes. You can read a bit more about what is going on in this thread: https://forums.unraid.net/topic/191221-some-musings-on-smb-and-samba-and-unraid-and-windows/ Understand that many Docker Containers run under Linux and access the Unraid file system directly using standard Linux file commands. Further if the container was not specially prepared to work with Unraid (and many are not!), they may use the standard Linux file permissions which are 755 for directories and 644 for files as these re the current security recommendations for most Linux distributions.

I think you will find this a bit difficult to actually do. You would be transferring several different files and directories for each type of update. It would require that you become an expert on how Unraid works and which files are updated with the different types of upgrades that you want your Unraid server to have. Exactly why are you air-gapping your server? If you can tell us that ,it would help. And how are using your server such that it is never exposed to the Internet. Unless you are iar-gapping your entire LAN, it is already exposed!!!

I can only imagine your frustration.... Try a "USB2" port-- you may have to consult the MB manual. (Some MB USB3 ports are not always handled well when used to boot Unraid and they tend to get 'lost' in the process. The source of the problem has never been identified.)

It is a matter of personal preference. I think the notice is there to help those folks who want/need to switch from Flash Drive boot to booting from a more reliable device. I suspect that it launches a wizard to walk them through the process. (Us folks who are fortunate to have a good quality flash drive from the 2010 era or to have a USB SD memory card adapter are in a much better position than those using 2026 era flash drives!!!)

@Ksanto , I agree with @trurl. I am wondering how you created a share on the cache drive without creating a Share. I suspect you must have been working down at the Linux level. It seems to me that transfer from TrueNAS is often done by using Linux tools like rsync (or one of its derivatives) to do the move. I have a suspicion that you might also be using Disk Shares rather than User Shares. Disk Shares are described here: https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/shares/#disk-shares Note these precautions if you are using Disk Shares:

It sounds like you created the Shares on the cache drive. A Share is automatically created whenever a folder/directory is created in the 'root' of a drive that is part of a cache or the array. Let me point you first to this section of the Unraid docs: https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/shares/#user-shares This is 'official' way to create a share BUT that backdoor way of creating a folder/directory also exists. It can bite the unwary if you don't realize that Unraid can be configured to have Primary and Secondary storage location. See here for that: https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/shares/#primary-and-secondary-storage Why us this primary/secondary option available? It is because writing to cache location first is (at least) twice as fast as writing directly to the array! But it does require that you configure the Share properly to use this option. (If you use the backdoor, you have to go looking for these settings.) If you create the share using the instructions in the first link that I provided, the settings are presented to you to set when you create the share.

You only other thing that I would know to do is to use a secure password to log in as the 'user' on the laptop. Not completely foolproof but it will slow things down for 'most' people who might want to access it.

You might want to pursue that issue in this sub-forum: https://forums.unraid.net/forum/111-tailscale/

Just remember to keep that computer secure. A lost/stolen laptop could make gaining access to your files a simple matter...

Understand that Unraid is never intended to on on the WAN (or Internet, if you prefer). It expects that all users will be on a secured LAN (Local Area Network). Tailscale is designed to to provide a secured tunnel through the WAN to your server from a remote known client. Any user that comes in via Tailscale is considered to a Local user.

You need to understand Samba and SMB a little bit more. Read the thread that contains this post: https://forums.unraid.net/topic/191221-some-musings-on-smb-and-samba-and-unraid-and-windows/#findComment-1561581 The next two posts explain how to set up your Unraid server and Windows clients to use SMB/Samba. The entire thread is a short explanation of the how's and why's of SMB and Samba.

The user root is not allowed as a SMB user!!! See the outpout from a SMB command that shows some of the SMB parameters that are used by Unraid:

Look at this thread starting here: https://forums.unraid.net/topic/191221-some-musings-on-smb-and-samba-and-unraid-and-windows/#findComment-1561581 And read the next two posts after that. If you have Windows Credentials already set up for this server, I would suggest deleting them and starting over.

Where is your diagnostics file and a detailed list of containers that are missing. These are all things that will be needed before your problems can be solved. It would also be better if you were to open a thread in the General Support forum as your problem may take several responses to address.

One more thing. If your users are accessing your server remotely, consider using Tailscale. The plugin is integrated into Unraid and it is free and secure. You can find more information in the Unraid Manual here: https://docs.unraid.net/unraid-os/system-administration/secure-your-server/tailscale/ I have family members accessing a share on one of my Unraid servers using a mapped drive that connects at startup.

I don't see what you are saving– clutter wise. You will still have the twenty shares on the second server. You can always name the Custom SMB generated share as (example)– Austins Files A mapped drive (mounted at Windows startup in the background) on Windows does the same thing. Once setup the PC user is not even aware that it is not a local drive. (Mapped drives are often required for Windows programs that can not access files via a network. There are not many of them these days but some of the legacy ones don't have a up-to-date replacement.) In fact, most recent Windows programs 'remember' the last folder/directory used and automatically open it when a file operation is requested.

Nope, they are going to show up there regardless of how you create the shares. (I thought you were trying to isolate an existing file tree by user rather than making a less cluttered display.) Mapping the shares onto the individual PC according their 'need-to-know' is the only way I know to hide the details.

What will happen is that once you set up a custom SMB share using the plugin is that custom share will show up in the "root" of the server in Windows File Explorer. To show what this looks like, here is a screen capture of my test server in Windows File Explorer: I have circled the Custom SMB share (SymLinkShare) that I setup to test this plugin out when it was being developed. I can then map that share as a mapped drive in Windows. If you still confused install the plugin and test it out. I think you will find that it will do exactly what you are looking for. Below is a screenshot of that share mapped as drive X: on my desktop: You can use any letter between A and Z to map the drive as long as it has not been previously assinged. It seems to be a convention to start at the end of the alphabet for mapped drives as Windows starts at the beginning to assign drive letters to both permanent and temporary drives.

Yes. I can't see why you would be prevented from creating with that naming scheme. (It was probably my fault for using "/MainSharedFolder/Subfolder". It might have been more clear if I had used "/MainSharedFolder/sub-folder" Where "sub-folder" represents any folder.) On second thought, Let me clarify a bit more. If you are creating and naming a Custom SMB share using the plugin, why would you want to use a path descriptor as the name? Most of the time, you are trying to restrict access to a user to only a section of the 'Mother' Share. (And in many cases, you want to hide the rest of the share from that user.) Why not name it "User1-Data' of some other descriptor that is meaningful to the User1?

No. Viewing = Read. Read Permission on any Unraid share means you are reading if you are seeing. EDIT: A bit of clarification. You will be able to see the name of this share (MainSharedFolder) but not able to see the contents of it. Obviously, any user with read permissions will be able to see the various /MainSharedFolder/Subfolder contents. Most of the time, The Admin1 login would have read privileges to the MainSharedFolder share and all of the sub-folders beneath it. That is the reason why most people setup Admin accounts!