suddenly no write permission anymore


Recommended Posts

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)

no_write_permission.JPG.034f01d4fd5c7f63b5da0564b88aaa74.JPG

Link to comment

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.

Link to comment

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.
Link to comment

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.
Link to comment

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)

Link to comment

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?

Link to comment

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)
Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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?

Link to comment

ok, that was easy :D

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)

Link to comment

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)

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.