Datulab Posted March 7, 2016 Share Posted March 7, 2016 Hello everyone While I was working on my unraid 6 server and adding it to owncloud, I pretty much suddenly lost write permission on some folders in a share. When I go into the advanced security settings of that folder, nobody (unix user \nobody) is the only user that has full access. The others only have read and execution permission. (as shown in the picture) But because I am someone and not nobody I don't have permission to do anything else than reading. -> I can't create new users or modify any settings of existing ones. Is there a way to solve that issue except starting from scratch? (which I don't want to do if somehow possible) Quote Link to comment
trurl Posted March 7, 2016 Share Posted March 7, 2016 Are these public shares? users/nobody is the default for all files on unRAID and that is correct. You really shouldn't be looking at this from a Windows share security perspective, and definitely shouldn't try to change this from Windows. The only thing that should matter is the SMB security settings for the particular share you are trying to access. If it is public then everyone has read/write. If you have set it to secure or private then you need to connect to your server with a user that has permission. You may have to go into Control Panel - Credential Manager and delete any credentials for your unRAID to get Windows to make you login again since it will remember how you connected to it before and will continue to use that. Windows only allows network connections to shares by a single user per remote machine and it won't even prompt you to login, it will just keep using the login it has already established and tell you access denied. Quote Link to comment
Datulab Posted March 7, 2016 Author Share Posted March 7, 2016 The nobody user I was talking about is on the windows side of things. The share is a privat one and I am connected to it. The thing is, that I have full read/write permission on some folders on the same share and only read permission in others. Quote Link to comment
itimpi Posted March 7, 2016 Share Posted March 7, 2016 The nobody user I was talking about is on the windows side of things. The share is a privat one and I am connected to it. The thing is, that I have full read/write permission on some folders on the same share and only read permission in others. With Windows it is important that you first connect to the private shares before the public ones. This is because Windows does not handle the other way around properly, and can give a misleading error message. You may have to first go into Windows Credential manager to clear any stored credentials for the unRAID server. Quote Link to comment
trurl Posted March 7, 2016 Share Posted March 7, 2016 The nobody user I was talking about is on the windows side of things. The share is a privat one and I am connected to it. The thing is, that I have full read/write permission on some folders on the same share and only read permission in others. Forget about what you are seeing on the windows side of things. Close that window that you got that screenshot from and don't look at it again. Concentrate on the other things we have already suggested. Quote Link to comment
Datulab Posted March 7, 2016 Author Share Posted March 7, 2016 That is not the problem because everything worked on the pc and I had full access to the privat share. (just to make sure, I disconnected all shares and connected again with no change of the situation) I can still use most of the share just normal only certain sub folders of the share have the problem. (and no, I'm not talking about the window but the actual problem that I can't write in those folders) Quote Link to comment
JonathanM Posted March 7, 2016 Share Posted March 7, 2016 My guess would be that one of your disks is mounted read only because of file system corruption. Without the diagnostics zip file, we are pretty much shooting in the dark. Quote Link to comment
Datulab Posted March 7, 2016 Author Share Posted March 7, 2016 My guess would be that one of your disks is mounted read only because of file system corruption. Without the diagnostics zip file, we are pretty much shooting in the dark. It can't be a whole disc because in most folders on the same disk I don't have the problem. How do I get the diagnostics zip file? Quote Link to comment
trurl Posted March 7, 2016 Share Posted March 7, 2016 My guess would be that one of your disks is mounted read only because of file system corruption. Without the diagnostics zip file, we are pretty much shooting in the dark. It can't be a whole disc because in most folders on the same disk I don't have the problem. How do I get the diagnostics zip file? By reading the Need help? sticky at the top of this subforum (and linked in my sig) Quote Link to comment
itimpi Posted March 7, 2016 Share Posted March 7, 2016 How do I get the diagnostics zip file? Tools->Diagnostics or by using the 'diagnostics' command from a telnet/ssh session Quote Link to comment
Datulab Posted March 7, 2016 Author Share Posted March 7, 2016 because the file is to big to attach, here is a dropbox link to it: https://www.dropbox.com/s/4jeoh59r89ekh92/media-diagnostics-20160307-2103.zip?dl=0 Quote Link to comment
trurl Posted March 7, 2016 Share Posted March 7, 2016 Syslogs mostly just show mover running every hour, sometimes it is still running when the next scheduled run tries to start. Some things in the mover runs that might suggest filesystem corruption but not sure. Nothing there that really shows your drives mounting which probably happened so long ago that those syslogs aren't available anymore. You might try stopping and starting the array and get another diagnostic for us. Quote Link to comment
Datulab Posted March 7, 2016 Author Share Posted March 7, 2016 When the mover was running so long at once I was probably copying the terrabytes of data on the array. The array also was online for over two weeks. Here is the new one: https://www.dropbox.com/s/3ml6yhdc7bm1zr7/media-diagnostics-20160307-2124.zip?dl=0 Quote Link to comment
Datulab Posted March 8, 2016 Author Share Posted March 8, 2016 Is there no one that has an idea? Quote Link to comment
trurl Posted March 8, 2016 Share Posted March 8, 2016 Nothing obvious. Filesystem check wouldn't hurt. Quote Link to comment
Datulab Posted March 8, 2016 Author Share Posted March 8, 2016 So I was just experimenting some more and got another clue. When I set the share (the one with the problematic folders) to public I don't have any problem anymore. But when I set it to private and allow only one account to have full read/write permission from unraid it doesn't work anymore, although I am connected with the account that should have read/write permission from unraid. Quote Link to comment
trurl Posted March 8, 2016 Share Posted March 8, 2016 Do you know how to get to one of your problem folders from the unRAID command line? Quote Link to comment
Datulab Posted March 8, 2016 Author Share Posted March 8, 2016 No, I don't. I never used the Unraid command line, but if we can solve the problem that way I am happy to learn it. Do you have a link to a good instruction? Btw I noticed something really strange. When the problematic share is set to private I also don't have write permission on a completely different share that is set to public. But when I have the first share (which has nothing to do with the second one) on public I have full read/write permission on the second share. Quote Link to comment
trurl Posted March 8, 2016 Share Posted March 8, 2016 Do these shares use the cache drive? Have you tried checking the filesystem yet? Quote Link to comment
Datulab Posted March 9, 2016 Author Share Posted March 9, 2016 The first share (the main problem) uses the cash disk and is located on disc 1. The second share (the one that is acting special) is located on the cash disc because it is used for application data. No I haven't checked the filesystem yet. How do I do that? Quote Link to comment
trurl Posted March 9, 2016 Share Posted March 9, 2016 Never actually needed to do it myself but here is the wiki: Check Disk Filesystems You might also try searching the forum. See search tips in my sig. Quote Link to comment
Datulab Posted March 9, 2016 Author Share Posted March 9, 2016 ok, that was easy Here is the report: Phase 1 - find and verify superblock... Phase 2 - using internal log - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 1 - agno = 0 - agno = 3 - agno = 2 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. According to the wiki this should be fine (if I understood correctly) Quote Link to comment
trurl Posted March 9, 2016 Share Posted March 9, 2016 I don't really know what it means. Take a look at this recent post by another mod: Checking XFS file system Quote Link to comment
Datulab Posted March 9, 2016 Author Share Posted March 9, 2016 As he noticed in his post the tool doesn't tell you if it is good or not. For good measures I ran the repair utility too but nothing changed so I guess a bad file system is not the problem. Do you have any other Idea to solve the issue? Other ways I will probably just copy the files over to another share and delete the problematic one. (I hope this works) Quote Link to comment
Recommended Posts
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.