8 minutes ago, Necrotic said:

Hi Frank,

I did this as it was recommended on one of the posts to prepare for the future but now I can't delete stuff on the share. How do I fix this? do I need to upgrade the permission on my user?

 

Run the    New Permissions    tool (  TOOLS    >>>   New Permissions    ) on just the Share with the problem and see if that fixes it. 

9 minutes ago, Frank1940 said:

 

Run the    New Permissions    tool (  TOOLS    >>>   New Permissions    ) on just the Share with the problem and see if that fixes it. 

That worked, Thanks!. I guess it wasn't related to the new user but some other misconfiguration? Its either Sab or couch...

Edited December 5, 20241 yr by Necrotic

9 hours ago, Necrotic said:

That worked, Thanks!. I guess it wasn't related to the new user but some other misconfiguration? Its either Sab or couch...

 

See this table from this post:

 

           https://forums.unraid.net/topic/131730-update-from-69-to-6115-and-got-permission-denied/#comment-1219731

 

The problem comes because Unraid needs permissions of 666 for files and 777 for  directories.  Many Dockers set the permissions for files that they generate as 644 for files and 755 for directories which means that 'group' and 'other' do not have write permissions.  The UMASK variable of 000 will fix this.  The PGID sets the proper group for Unraid Samba to work correctly. 

 

EDIT:  December 5, 2024

 

Let me expand on this a bit as it may help those with permission issues understand how Unraid has configured Samba in Unraid.  I have gleaned this information through analyzing what things work and don't work.  A forensic investigation if you like.

 

This investigation indicates that Samba (as LimeTech has it setup) uses the group permission for most Share Access user access.  Look at what the default owner, group and permissions are for files written directly from a Windows PC writing files (over a period of time) to the array:

 

 

Notice that there are three different owners for this group of three videos and their files---  smbuser, user and nobody.  There is only one group--- users.  If you do some investigating, you will find that all three of the 'user names' are members of the 'users' group.  Note that the permissions are identical for both owner and group-- rx-  

 

I can assure you that this share is Private and users 'smbuser' and 'user' can have full read/write privileges to all of these files regardless of who owns them!  The only way that this can happen is because that LimeTech has set up Samba in Unraid so that it is expected that the file access will be controlled through the 'group' privileges/permissions-- not through 'owner'.

 

The same argument might be made for those connections are using the Guest access when accessing public shares.  They are using the 'other' permissions. 

 

This is the reason that underlying Linux Permissions must 666 for files and 777 for directories. 

Edited December 5, 20241 yr by Frank1940

On 1/27/2019 at 8:07 PM, StrandedPirate said:

Tons of posts related to Windows 10 and SMB as the root cause of the inability to connect to unRaid that were fruitless so I'm recording this easy fix for my future self.

 

If you cannot access your unRaid shares via DNS name ( \\tower ) and/or via ip address ( \\192.168.x.y ) then try this. These steps do NOT require you to enable SMB 1.0; which is insecure.

 

Directions:

1. Press the Windows key + R shortcut to open the Run command window.
2. Type in gpedit.msc and press OK.

3. Select Computer Configuration -> Administrative Templates -> Network -> Lanman Workstation and double click Enable insecure guest logons and set it to Enabled.

4. Now attempt to access \\tower

 

I think it's a bug in windows (what Microsoft probably calls a security feature).

 

I just had the same problem.... and fixed it without changing any security policies.

The problem is typically due to the illogical nature of Windows:

https://blog.thul.org/technik/betriebssysteme/gastzugang-auf-netzwerkfreigaben-systemfehler-1272/

(german webpage)

 

Instead of asking for an alternative user because guest access is not allowed, Windows spits out a meaningless error message when entering:

 

net use X: \\SERVER-IP\[shared folder]

 

 

The solution can be found in this very amusing post:

https://spackmat.de/spackblog/archives/830-Kein-Zugriff-auf-NASSambaSynology-von-Domaenenrechnern-aus-Gastkonto-deaktivieren!.html

 

You simply have to use the command "net use" always together with the username:

net use X: \\SERVER-IP\[shared folder]  /user:[Unraid user]

 

Maybe reset existing connections with wrong authentication beforehand with:

net use * /delete

 

After I did it this way i finally was also able to open my server shares by just entering the IP address in Windows Explorer \\xxx.xxx.xxx

 

The next terrible behavior of windows:
After the creation of the first network drive... if you want to connect more drives with the same Unraid user, then you have to leave out the part with the user name ("/user:xxx") in net use...  otherwise you will get the next confusing error message from windows:

 

 

 

 

 

https://learn.microsoft.com/en-us/windows-server/storage/file-server/enable-insecure-guest-logons-smb2-and-smb3?tabs=powershell

 

On 12/4/2024 at 10:09 PM, Frank1940 said:

 

See this table from this post:

 

           https://forums.unraid.net/topic/131730-update-from-69-to-6115-and-got-permission-denied/#comment-1219731

 

The problem comes because Unraid needs permissions of 666 for files and 777 for  directories.  Many Dockers set the permissions for files that they generate as 644 for files and 755 for directories which means that 'group' and 'other' do not have write permissions.  The UMASK variable of 000 will fix this.  The PGID sets the proper group for Unraid Samba to work correctly. 

 

EDIT:  December 5, 2024

 

Let me expand on this a bit as it may help those with permission issues understand how Unraid has configured Samba in Unraid.  I have gleaned this information through analyzing what things work and don't work.  A forensic investigation if you like.

 

This investigation indicates that Samba (as LimeTech has it setup) uses the group permission for most Share Access user access.  Look at what the default owner, group and permissions are for files written directly from a Windows PC writing files (over a period of time) to the array:

 

 

Notice that there are three different owners for this group of three videos and their files---  smbuser, user and nobody.  There is only one group--- users.  If you do some investigating, you will find that all three of the 'user names' are members of the 'users' group.  Note that the permissions are identical for both owner and group-- rx-  

 

I can assure you that this share is Private and users 'smbuser' and 'user' can have full read/write privileges to all of these files regardless of who owns them!  The only way that this can happen is because that LimeTech has set up Samba in Unraid so that it is expected that the file access will be controlled through the 'group' privileges/permissions-- not through 'owner'.

 

The same argument might be made for those connections are using the Guest access when accessing public shares.  They are using the 'other' permissions. 

 

This is the reason that underlying Linux Permissions must 666 for files and 777 for directories. 

Thanks for this, I was able to try this now that I am back. I found a place in sab where it asked me for permissions so I set it to 777 (it didn't specify if its for files or folders, but per the hint it seems to be folders)

Couch was straightforward as well, just updated this part:

For Sonarr I found the permission part as well, changed it to 777. Anyone with experience setting this up can you provide feedback on following:
- Do I need to click on the set permission tickbox to get it to work?
- Should I also set the chown Group to 100?

I tried unRAID for the first time yesterday and also had the problem that I couldn't connect to the network drives. To solve the problem, I added and removed the shares several times until it eventually worked. A bit strange, but it has been working since then.

Thank you! You are a legend. 

On 1/27/2019 at 2:07 PM, StrandedPirate said:

Tons of posts related to Windows 10 and SMB as the root cause of the inability to connect to unRaid that were fruitless so I'm recording this easy fix for my future self.

 

If you cannot access your unRaid shares via DNS name ( \\tower ) and/or via ip address ( \\192.168.x.y ) then try this. These steps do NOT require you to enable SMB 1.0; which is insecure.

 

Directions:

1. Press the Windows key + R shortcut to open the Run command window.
2. Type in gpedit.msc and press OK.

3. Select Computer Configuration -> Administrative Templates -> Network -> Lanman Workstation and double click Enable insecure guest logons and set it to Enabled.

4. Now attempt to access \\tower

 

Related Errors:

• Windows cannot access \\tower
• Windows cannot access \\192.168.1.102
• You can't access this shared folder because your organization's security policies block unauthenticated guest access. These policies help protect your PC from unsafe or malicious devices on the network.

 

 

this don't work glade it didn't say there Was a fix at least how has this been going on for over 10 years and not yet a fix for it when you have to reinstall windows every 7 to 100 days just to get access to the server sicking 

On 1/27/2019 at 9:38 PM, srandolph said:

If as you try to access unsecure unRAID, you see this panel, insert \ backslash for user ID and click OK, your in.

this works still in 2025

6 hours ago, PetrusMagna said:

this works still in 2025

This only works IF your Windows computer will allow 'guest' connections to a server...

On 4/20/2025 at 8:47 PM, Shady420 said:

when you have to reinstall windows every 7 to 100 days just to get access to the server sicking 

I have never had to reinstall Windows for this reason as long as the credentials are correctly set in windows Credentials Manager.

I dealt with this for a whole year. I tried everything smb 1 2 3 etc, Windows features on and off, user perms till I was blue in the face. The only thing that worked was a fresh install of Windows.

Sometimes windows just is borked and have to admit defeat; you should of seen my face the first time it worked on the first try.

Edited October 18, 2025Oct 18 by Fiservedpi

registry file

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]

"EnablePlainTextPassword"=dword:00000000

"EnableSecuritySignature"=dword:00000001

"ServiceDll"=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,\

00,74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,\

77,00,6b,00,73,00,73,00,76,00,63,00,2e,00,64,00,6c,00,6c,00,00,00

"ServiceDllUnloadOnStop"=dword:00000001

"RequireSecuritySignature"=dword:00000000

"AllowInsecureGuestAuth"=dword:00000001

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters


Mainliny ists allow insecure guest auth 1 and require security signature 0 ...

NTLM also plays a role here.. each window env is different...

lanmanworkstation.reg

Edited November 24, 2025Nov 24 by bmartino1