BlueBell

This is 100% an issue with Samba 4.17 and the later versions of Unraid. What I'd like to know, is it possible to manually upgrade Samba to the the latest stable release, 4.19.5? This was the last thing I started to experiment with but haven't yet had time to continue.... I thought I might be able to use NerdTools, but there doesn't seem to be Samba available there...

Well... after a bit of testing, it doesn't seem to have anything to do with the smb.conf file... After running testparm -v on the fedora and unraid system, I identified a list of parameters on fedora that were different. [global] bind interfaces only = No host msdfs = Yes map to guest = Never max open files = 16384 multicast dns register = Yes ntlm auth = ntlmv2-only null passwords = No passdb backend = tdbsam server min protocol = SMB2_02 acl allow execute always = No aio read size = 1 aio write size = 1 create mask = 0744 directory mask = 0755 use sendfile = No wide links = No The above changes were pushed into /boot/config/smb-extras.conf, and smb restarted... no changes to the issue at hand (although I'm keen to revisit this for performance tuning in the future, such as the aio read/write size) Note: I did try 0777 on both the masks to no affect. There were also some other different parameters but they were either, completely unrelated (printer stuff), file path related, or flat out broke SMB after implementing... all those have been omitted from the list above. I think from here... I might try to repeat the above using a slackware vm install... but other than that, a bit lost for now

Thank you both for the info. Far more has been thrown on my plate than I anticipated this week... but I will conduct further testing with it in the coming weeks when I eventually find some time to do so... will report back here when I either find something or run out of ideas.

For the sake of uniting anyone following this thread... visit:

Unfortunately the main post is under General instead of this Topic, but please follow along with the larger, original thread for any updates/assistance

Hi all, a nobody here but thought I'd help dive in because it's just as frustrating to me too... So a quick recap for new and old returning members.... - Solid Explorer (and many other android file explorers) receive a permission denied error when attempting to delete a file/folder from an SMB share in recent versions of Unraid. The delete still occurs (as evident by refreshing the page), but an Access Denied error is still received by the client. - CX File Explorer is one of few apps that can delete and does not show any error. Suspect that it simply does a better job at handling the crap sent from Unraid. - This is not an issue when accessing from windows or Linux systems. - This is not a Samba issue. - Although Solid Explorer could deal with the error better, the root cause is with Unraid. So far, I've tried to just verify and replicate findings from others... here is said info: Unraid Version: 6.12.4 Samba Version: 4.17.10 Solid Explorer Version: 2.8.35 I set up SMB for a new share and connected via CX and Solid Explorer. I could successfully create and delete items in the share using CX without issues. I clearly experienced the subject symptoms when working with Solid Explorer... created a file fine, denied to delete it, refreshed and saw it was removed. I then set up a Fedora 37 VM and installed the same version of Samba (4.17.10) and followed the instructions here for configuration: https://techviewleo.com/install-configure-samba-share-on-fedora/ I then repeated the test actions with Solid Explorer after connecting to the new Fedora SMB share, and it worked perfectly... as expected after hearing Samba on other systems works fine. So we can safely say this is an Unraid issue. In terms of configuration differences... I noted I HAD to add the share folder in fedora to "samba_share_t" in SELinux. Without doing so, I had no access to the share. Unraid/slackware don't seem to have SELinux. I also found some differences in the smb.conf stuff, but after making changes to it in Fedora, you call "systemctl restart smb" to allow the changes to take effect. The command is not valid in Unraid and so the only way I thought of "restarting" smb in Unraid was to stop the array, turn off smb, turn on smb, start the array... this however simply reverted any and all changes made to smb.conf and smb-shares.conf on Unraid, so I don't know how to verify if any changes there will work. Lastly, I haven't yet looked into the firewall configuration in Unraid as that was needed in Fedora to allow access... just something else to rule out. Hopefully there's someone out here now that is willing to work through it with me. EDIT: If someone on an older version of Unraid that doesn't experience the Solid Explorer access issue, could share their /etc/samba/smb.conf and smb-share.conf files, it would be good to directly compare with my files to see if that's where the issue lies.

Hi all, I've successfully installed this Tailscale docker image on my unRAID server and have remote access. After reading though this article (https://tailscale.com/blog/tls-certs/), I concurred that I don't like having the browsers tell me the certificates are invalid etc and wanted to enable the Tailscale HTTPS certificates for use with my other docker containers (Jellyfin & NextCloud, however, they do nothing!? I have; enabled the HTTPS certificates setting on my Tailscale account. accessed the Tailscale docker image and ran the below command to successfully create the .key and .cert files. ./tailscale cert unraid.<server-alias>.ts.net edit NextCloud config file to add unraid.<server-alias>.ts.net to the 'trusted domains' using my remotely connected phone or pc, attempt to access the main unRAID server at https://unraid.<server-alias>.ts.net -> this results in a successful but insecure connection due to the certificate being selfsigned. " attempt to access the main unRAID server at https://unraid.<server-alias>.ts.net:<nextcloud_port_number> -> successful but insecure connection due to the CA Authority being invalid " attempt to access the main unRAID server at https://unraid.<server-alias>.ts.net:<jellyfin_port_number> -> unsuccessful connection... "connection refused" this does however work if I use the same address above just with 'http', but then it just complains it isn't secure. Can anyone help me identify what I'm missing here and why these certificates have no affect, particularly on my docker containers? I'd most prefer to get the HTTPS certificates working so the browsers don't complain... failing this, I guess it's fine to just ignore it since its all encrypted through the VPN anyway, right? EDIT: Just to clarify, the .crt and .key files are still in the location they were created... within the /app folder of the Tailscale docker container. Do these need to be moved/installed somehow?