Constant problems with SMB permissions


Recommended Posts

I'm constantly pulling my hair out regarding permissions issues with my Unraid server. I have found temporary fixes here and there but the problems always return. The primary issue I run into is the inability to delete files on certain shares. I encounter this issue when accessing my shares via SMB from both my Windows 10 computer and my laptop running Mac OSX 10.13. Let's say I have a user 'lock' set up with read/write privileges to a folder 'downloads.' When I try to delete certain files in 'downloads,' it says I do not have permission to do delete those files. I have tried the 'new permissions' utility in the past with some success. I just tried it again and now Windows isn't even giving me access to read the files despite typing in the correct username and password! Please help me fix this problem for good. Let me know what other information you need. I am running Unraid 6.3.5 (and have only ever uses Unraid 6).

 

Edit: Well it just seemed to start working again. Able to delete files appropriately via Windows and my Mac. Still really wish I could find a way to prevent this from happening all the time.

Edited by lockdown571
Link to comment

I would suggest starting by reading  these threads:

 

      https://lime-technology.com/forums/topic/25064-user-share-problem/?tab=comments#comment-228392

And read on for another eight to ten posts

 

And this entire thread:

      https://lime-technology.com/forums/topic/53172-windows-issues-with-unraid/     

While this pertains a lot to Windows issues, it also has a lot of SMB wisdom and knowledge in it.  SMB is wonderful when it works but when one has a problem(s), it often seems that witchcraft is necessary to fix them. 

 

There is also a thread about some Win10 issues that might be of some help:

      https://lime-technology.com/forums/topic/57626-intermittent-unresponsive-samba/#comment-564712

Apparently, MS is 'securing' SMB in Win10 (they unilaterally control the SMB 'spec'.) and are continually to make changes to Win10 achieve that goal.  The Linux SMB group is always playing catchup to these changes.

 

  • Like 1
Link to comment

There is also an issue with vfs_fruit causing this sort of problem. You don’t mention whether the files were created by the windows machine or the Mac, but if it was the Mac and you have vfs_fruit enabled on your unRAID server (enhanced OSX compatibility) you may see the same problems.

 

More details and a possible fix-

https://lime-technology.com/forums/topic/59899-635permission-issues-with-smb-shares-when-connecting-from-a-mac/

Link to comment

Thanks for the help! I've seen some of those threads before. Many of the recommendations involve fiddling with Windows username and passwords. Regarding wgstarks post, the majority of these files were created by the windows machine, and I do not have vfs_fruit enabled. What's always seemed bizarre to me, is that this surely is an extremely common usage scenario, i.e., accessing files on your Unraid server from a Windows machine over SMB. Seems like these issues would be widespread. There's nothing particularly unusual from my setup from what I can tell. I mean, are the majority of people using linux or accessing files over a different network protocol? Anyways, I guess I'll do a bit more digging into those threads. I had similar issues with permissions back when I was using Flexraid too. It is a constant headache.

Link to comment

With Windows machines, it depends on what version of windows you are are running (XP, Win7, Win8 or Win10).  The newer the version, i(t seems) the more the problems.  Since Windows is the major OS used on PC's worldwide by a large percentage, it stands to reason that is also the most used PC with unRAID.  (But the actual percentage may be lower.) 

 

It is my personal opinion that the problems with SMB are many fold:  

 

First, there is no actual specification or controlling body for SMB.  It is strictly a MS creation.  Apparently, there is no written document from MS which details how it should work.  But it has been reversed engineered extensively and most OS have client/server version of it available.  The Linux version is officially Samba.  When MS incorporates some new wrinkle into SMB, they figure out how to include it into Samba without breaking legacy usages.

 

Second, it is a Kludge.  It started out back with DOS and went big time when Windows for Workgroups 3.1 was introduced back in 1992 and was intended to allow for a small number of PC's to be able to share data and resources without requiring a dedicated server (i.e.,  peer-to-peer networking).  There was no security.  In fact, I would be very surprised if you couldn't connect a Windows for Workgroup computer to your current SMB network and have it connect.  

 

A third factor is complicating the Win10 situation.  There are (at least) four different versions of it--  Home, Pro Enterprise, and Educational.  Plus, there are currently three different number versions available (1607, 1511, and 1703).  Security is the one marked difference between these versions and  it is a constantly moving target.  When MS changes the way it provides security in anyone of these combinations of releases, it may well affect only the users of that version.  So user 'A' Win10 machine works user 'B' Win10 machine breaks!

 

One problem that many people don't realize is that the polling time for SMB is very long.  (Remember,the first version of SMB was introduced when a 80386-20MHz and 1MB of RAM was the king of the hill!)  It can take a long time for a SMB network to become fully synchronized!  (We are talking up to an hour or more!)  That is why, it is strongly suggested that you set your unRAID server to allow it to become the Local Master and leave it on 24-7.   In fact, you can actually force your server to always become the Local Master during the "election" process and that can be a good idea in many cases.  (I have the feeling that your PC remembers which computer was the last Local Master when you shutdown.)  This action alone has solved many folks' issues with not being able to access their server when turning on their PC.  

 

Finally, fixing SMB problems is more witchcraft than science.  There is no one solution to solving any problem.  And,  in some cases, there are a number of totally different solutions which will fix the same problem.  In some cases, it just seems to fix itself.  It is absolutely madding!  There have been attempts to collect together many of the solutions which have worked in the past and I provided a link to some of them in the second post in this thread.  

  • Like 1
Link to comment

I'm not sure if this is related or not but I do at times run into a situation that I get an error message that I can not delete a file, "File Busy" from my Mac from within the app that created it.

it is always a newly saved/created file. If I quit the app that created it or restart the Mac I can delete that file from within the app that created it. It seems that the app has not released possession of it until the app has been closed.  This only happens with UnRaid and SMB and never with files saved locally. Since I normally shut down the system at night I just delete it the next day after a restart.

 

Link to comment

@Russ Uno   No one else has jumped in to attempt to answer your question.   I am no expert on MC OS or program since I am a  Windows guy on the PC front with all types of devices that run Linux attached to the network here.  

 

I was surprised when you said that you could delete a file from the app that created it.  I have been thinking since I read that statement and I can't think of a single Windows application that you can do that with.  But be that as it may, I have the feeling that SMB has associated the file lock to that app (not the file) and when the app closes that file, the lock is not released.   I do have not any thoughts about why it would behave differently under the MAC OS than under SMB.  

 

But on a slightly higher plane of thought, SMB is erring on the side of safety.  You definitely don't want a file to be open for read-write operations in two sessions simultaneously!  (Deleting a file is a read-write operation.)  That is a recipe for disaster of the first magnitude! 

 

Have you checked to see if the file is on another MAC computer if you can still do this operation that fails when the file is on your unRAID server?  If it works (or not), what file sharing protocol did the MAC's use?

 

Can you delete the file from the file manager for your MAC after closing it in the app with the app still open? 

 

PS ---- Why would one want to delete a file that one had just opened for editing?

Link to comment

I think it's just a bug in the app - it doesn't properly closes the file after having created it.

 

Open files can't be deleted. When operating natively on the file system, it's allowed to issue a delete and have the file name disappear from the directory. But the file data itself will remain until the file is finally closed.

 

Closing the app will result in an automatic close of the file.

Link to comment

Basically, No.  SMB is the major protocol used for networking today.  (Having said that, I am not really certain what is used inside large data centers and in Super Computer installations.) 

 

NFS is not a viable option as I have never heard of a Windows driver for it.  In addition to that, there are a fair number of problems with NFS.  The primary one being you have to use the actual IP address of every resource that you want to access which means basically, you have either assign an IP address to every computer on your network or setup your router so that it assigns a predetermined IP address to those devices.  Plus, there have been some issues with file handles in the past and I am not sure with those have ever been resolved.  (My gues would be that less than 5% of the unRAID users have ever used NFS. 

 

Many long years ago, there were a number of other network protocols but they all had license fees to use them.  NFS and SMB were basically free as they were 'packaged' in an OS.  It does's not  take much in slight to see why they ended up being the last ones standing...

Link to comment

Well, a bit of searching brought this to the forefront.

 

    https://social.technet.microsoft.com/Forums/windows/en-US/d7dd8330-5ac6-440c-95cc-cbda8e84e140/dose-windows-7-support-connecting-to-nfs-servers?forum=w7itpronetworking

 

I do know that it is not available for install on Windows 7 Home Premium from the standard install disks.  All of the pages that I could locate were fairly old and some the links didn't work any more.  I have heard that NFS may be becoming another one of the many protocols that are died out as a result of lack of interest (and support).  It used to have a much lower 'overhead' than SMB but that issue has been largely addressed in recent years even in Samba.  

Link to comment

Aaand the the problem is already back. Tried setting the Unraid server to local master, didn't help. This is maddening. I mean how the heck do people with enterprise solutions get SMB to work reliably. I'm going to try to switch everything to NFS. Found a guide to get NFS working in Windows 10: https://graspingtech.com/mount-nfs-share-windows-10/

Edited by lockdown571
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.