SkippyTheSnake

Members
  • Posts

    8
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

SkippyTheSnake's Achievements

Noob

Noob (1/14)

6

Reputation

  1. Okay, by default Docker containers use the root user, meaning any files they create also belong to the root user so maybe this is the issue. Some containers allow you to set a PUID and GUID. For example on my plex docker I have PLEX_UID=99 and PLEX_GID=100. This will tell the container what user id and group id to use.
  2. Interesting, must be something to do with cache drives then. I'd probably try experiment a bit to find a pattern. Create a new share and look at the permissions. Try creating a share without cache access, see if that has any affect. Check the permissions on "/mnt/user" or parent folders, maybe it's being inherited from a folder further up? Try creating files through windows/linux using SMB, see if their permissions are okay or if it's only files generated by docker or unraid itself.
  3. What kinds of permission issues? I think my ACL issue was caused by changing cache drives
  4. Obligatory warning to be mindful of this command. If you can make sure you have backups just in case something goes wrong. It worked fine for me and a couple others but I'm far from a Linux expert and wouldn't want to cause you any data loss. To just change that directory you would use: setfacl -b /mnt/user/NAS/Media If you have the same issue as me though, you more than likely want to do this recursively on all sub directories and files so just add the "R" argument: setfacl -Rb /mnt/user/NAS/Media
  5. I have been having some file permission issues in a number of places and I think I've tracked the issue down to my shares being created with ACL rules enabled. This occurs in a number of scenarios but the most problematic are when I have a docker container pointed at share A (without ACL) any files it creates I am able to access via SMB. If I point that same docker container to share B (with ACL) all of a sudden I can't access the files. If I enable caching on a share (wihout ACL) then transfer a file over to it the share becomes inaccessible. However once I run the mover I can access the share again. I think I've tracked this issue down to me having ACL rules on these affected directories. When I create a new share it's created with the permissions drwxrwxrwx+ and then the issues listed above occur. Once I remove the ACL the problems seem to be solved. Travelling up the directory tree I found that all of my drives and both the user and user0 directories have these same permissions with ACL. If I run ls -l in the /mnt directory I get the following output: total 8 drwxrwxrwx 5 root root 120 Feb 2 01:33 RecycleBin/ drwxrwxrwx+ 5 nobody users 57 Feb 1 23:11 cache/ drwxrwxrwx+ 16 nobody users 4096 Feb 2 01:27 disk1/ drwxrwxrwx+ 10 nobody users 118 Feb 1 23:11 disk2/ drwxrwxrwt 3 nobody users 60 Jan 25 18:25 disks/ drwxrwxrwx+ 1 nobody users 57 Feb 2 01:27 user/ drwxrwxrwx+ 1 nobody users 4096 Feb 2 01:27 user0/ As far as I can see the solution would just be to run setfacl -b on the affected directories to remove the ACL. Before I did this though I want to check that I've come to a logical conclusion and that by removing the ACL I won't cause any other permissions issues within Unraid. Is it normal to have these ACL rules on my shares or is there something wrong? I am unsure what kinds of actions I should perform to make my diagnostics log useful so I've just created a new share and verified that it was created with ACL rules. tower-diagnostics-20200202-1811.zip
  6. Sorry hopefully this is more useful. While doing this though I noticed the issue doesn't occur on new shares or shares I've created recently. So if there's no underlying issue it may just be a case of creating new shares to replace the old ones. tower-diagnostics-20190618-2246.zip
  7. I am relatively new to both Linux and Unraid and have come unstuck and don't know where to go with diagnosing this issue and I'm not having much luck googling the issue. So I have a share called 'Documents' with 'Use cache disk' enabled and I am exporting it with smb private share giving my user read/write permissions. I can access the share from Windows just fine until I create or copy a file to the share. Then I lose access to the share and Windows displays a network error saying I don't have permission to access the share. If I head to the Unraid web ui and run the mover I can then access the share again. This issue occurs on any share that I allow to use the cache disk. This makes me think that the file created on the cache drive doesn't have read permissions for my user. When I head into /mnt/user/cache I can see the folder with the share name 'Documents' and inside it is the file I copied. If I run ls -la the permissions are: drwxrwx---+ 2 nobody users The same permissions are set for the share when I navigate to /mnt/user/Documents both inside the Documents share file and for the Documents share itself. I also used the groups command to check my user had the group 'users' assigned and restarted the machine. I am running Windows 10 1809 on the client and Unraid 6.7.0 on the server. I'm not entirely sure when this issue arose but it could have been when I upgraded from Unraid 6.6. Any help would be appreciated, thanks.