ashman70 Posted October 26, 2016 Share Posted October 26, 2016 I have a share called Movies, it was set to private and I was connecting as a user who had read/write permissions until I encountered a couple of folders I was unable to delete. I am trying to delete them from a windows 10 and a mac and getting now where. I have changed the permissions on the share to public, still I am unable to delete the folders. On my windows 10 machine I get an error that says: You require permissions from the Unix User\nobody to make changes to this file What does that mean and why am I in this predicament? How can I delete these folders and how do I know I won't run into this in the future? Quote Link to comment
limetech Posted October 26, 2016 Share Posted October 26, 2016 Please post diagnostics.zip: Tools/Diagnostics Also seems like several ppl are reporting this. Please also capture output of this command: ls -lah /mnt/user/path/to/file Where "path/to/file" is the name of a file that you can't delete. Quote Link to comment
ashman70 Posted October 26, 2016 Author Share Posted October 26, 2016 I sent you a PM with the output you requested, I can't attach my diags because they are too large, here is a dropbox link. https://www.dropbox.com/s/y9a21q6zhq2z1e7/tower-diagnostics-20161026-1324.zip?dl=0 Thanks Quote Link to comment
limetech Posted October 26, 2016 Share Posted October 26, 2016 I sent you a PM with the output you requested, I can't attach my diags because they are too large, here is a dropbox link. https://www.dropbox.com/s/y9a21q6zhq2z1e7/tower-diagnostics-20161026-1324.zip?dl=0 Thanks Got it thanks. Here is the issue: in the listing you sent me via PM most of your files have these permissions: -rw-rw-rw- 1 ashman users But there are two files, an .nfo file and a .jpg file, that have these permissions: -rw-r--r-- 1 nobody users The problem is that group-write permission is not present on those two files. Normally if you are connected via username 'ashman' (in either windows or osx), since 'ashman' is in the same group as all the other users, and group-write permission is always set on files transferred to server via network, this is not a problem. But somehow on these two files the group-write permission was turned off, which means you have to be logged in as that exact user in order to delete it, which is the error you are seeing. The question then, how did you copy those two files to that share? Stated another way, how were those two files created on that share? Quote Link to comment
ashman70 Posted October 26, 2016 Author Share Posted October 26, 2016 I use a windows program called free file sync to replicate data from a share on a Synology NAS I have to this share on my unRAID server. The files would of gotten there via this manual synchronization. The odd thing is, and perhaps its not odd, but I can't delete any files in either of those folders as the user ashman. Shouldn't I be able to ? Quote Link to comment
limetech Posted October 26, 2016 Share Posted October 26, 2016 I use a windows program called free file sync to replicate data from a share on a Synology NAS I have to this share on my unRAID server. The files would of gotten there via this manual synchronization. The odd thing is, and perhaps its not odd, but I can't delete any files in either of those folders as the user ashman. Shouldn't I be able to ? The reason you can't delete is because of this: drwxr-xr-x 1 nobody users 41 Oct 26 11:22 ./ Again, group-write permission is off. This means only user 'nobody' can delete files from that directory. If group-write permission is on, then any user in the 'users' group (which is all users in unraid) would be able to delete files from that directory. I see why the issue is there but it's not clear how it's happening. How are files being transfered, SMB or NFS? In the logs it ooks like there is some NFS transfers going on. Why are you using NFS? BTW to correct this you can run the 'New Permissions' tool. Quote Link to comment
Squid Posted October 26, 2016 Share Posted October 26, 2016 BTW to correct this you can run the 'New Permissions' tool. Don't run New Permissions against all the drives if you use docker apps. You *may* impact the ability of the docker apps to run by changing the permissions in the appdata folder. Either exclude the cache drive, or run FCP's New Permissions tool which will automatically exclude appdata and backups of appdata Quote Link to comment
limetech Posted October 26, 2016 Share Posted October 26, 2016 BTW to correct this you can run the 'New Permissions' tool. Don't run New Permissions against all the drives if you use docker apps. You *may* impact the ability of the docker apps to run by changing the permissions in the appdata folder. Either exclude the cache drive, or run FCP's New Permissions tool which will automatically exclude appdata and backups of appdata I would have preferred appdata to be a loopback mounted image in order to avoid this problem, but I guess the horse has long left the barn for that. Quote Link to comment
ashman70 Posted October 26, 2016 Author Share Posted October 26, 2016 I am synchronizing the files through SMB shares, not NFS. Quote Link to comment
JonathanM Posted October 26, 2016 Share Posted October 26, 2016 I would have preferred appdata to be a loopback mounted image in order to avoid this problem, but I guess the horse has long left the barn for that. Genuinely curious, why do you say it's too late? We're currently transitioning from /mnt/cache/appdata to /mnt/user/appdata, so why would it be a stretch to mount an image at /mnt/user/appdata or elsewhere? Just as long as the image is size flexible, my appdata regularly shrinks to as little as 5GB to as much as 150GB or more as data is cycled in and out of it. I'd hate to permanently lose 150GB of SSD cache pool if the image didn't automatically shrink. Quote Link to comment
limetech Posted October 26, 2016 Share Posted October 26, 2016 I am synchronizing the files through SMB shares, not NFS. It should not be possible to set the file/directory permissions the way they are purely via windows networking unless some "tweaks" were made manually or via plugin to Samba config files. The other possibility is a plugin or maybe docker container is changing file permissions, or creating files/directories with the wrong permissions. Quote Link to comment
limetech Posted October 26, 2016 Share Posted October 26, 2016 I would have preferred appdata to be a loopback mounted image in order to avoid this problem, but I guess the horse has long left the barn for that. Genuinely curious, why do you say it's too late? We're currently transitioning from /mnt/cache/appdata to /mnt/user/appdata, so why would it be a stretch to mount an image at /mnt/user/appdata or elsewhere? Just as long as the image is size flexible, my appdata regularly shrinks to as little as 5GB to as much as 150GB or more as data is cycled in and out of it. I'd hate to permanently lose 150GB of SSD cache pool if the image didn't automatically shrink. Yes that's really the issue, that as a loopback image it has to be contained within one volume, and once space gets allocated, it doesn't get "freed" typically. There are other advantages to a loopback image, aka, vdisk image. For example it can be snapshotted (if on btrfs) and easily copied/backed up. Well this is the wrong topic to discuss this, but an item on the todo list is to augment New Permissions tool so that you can select user shares for which you want to "reset" the ownership/permissions. Quote Link to comment
ashman70 Posted October 27, 2016 Author Share Posted October 27, 2016 Any idea what I can do to delete these two files? I am not that great with the CLI but I can try and follow any instructions you might have. Thanks Quote Link to comment
limetech Posted October 27, 2016 Share Posted October 27, 2016 Any idea what I can do to delete these two files? I am not that great with the CLI but I can try and follow any instructions you might have. Thanks You can use 'midnight commander' (the 'mc' command) to bring up old-school graphical file manager. The command line runs as 'root' and root can do anything - so be careful Quote Link to comment
ashman70 Posted October 27, 2016 Author Share Posted October 27, 2016 Thanks but I wouldn't have a clue what to do, so I need some assistance if possible. Quote Link to comment
Msan Posted October 27, 2016 Share Posted October 27, 2016 Have you tried running the "New Permissions" tool in the tools tab/menu? Quote Link to comment
Squid Posted October 27, 2016 Share Posted October 27, 2016 Have you tried running the "New Permissions" tool in the tools tab/menu? BTW to correct this you can run the 'New Permissions' tool. Don't run New Permissions against all the drives if you use docker apps. You *may* impact the ability of the docker apps to run by changing the permissions in the appdata folder. Either exclude the cache drive, or run FCP's New Permissions tool which will automatically exclude appdata and backups of appdata Quote Link to comment
Msan Posted October 27, 2016 Share Posted October 27, 2016 Yes, I meant the one that has (Docker safe) underneath.. Quote Link to comment
ashman70 Posted October 27, 2016 Author Share Posted October 27, 2016 I found the disk that has the files on it, but I am confused about how to run the 'New permissions' tool. Also on this same drive is an appdata folder with some folders for dockers that I use. Quote Link to comment
Squid Posted October 27, 2016 Share Posted October 27, 2016 I found the disk that has the files on it, but I am confused about how to run the 'New permissions' tool. Also on this same drive is an appdata folder with some folders for dockers that I use. In that case, you can either drop to the command line to run the commands, or install the fix.common.problems plugin, and under the tools menu there will be a new icon labelled Docker Safe New Permissions, which will do the exact same thing as the LT version (it actually calls the LT script), but it specifically excludes the appdata share (and a CA backup of appdata if present). You can also add additional excluded shares via the FCP icon in the settings tab (eg: crashplan? backups, etc) Quote Link to comment
ashman70 Posted October 29, 2016 Author Share Posted October 29, 2016 Just wanted to report back that running the New Permissions (Docker Safe) tool fixed my problem. Thanks for the help. Quote Link to comment
Lappen71 Posted October 15, 2017 Share Posted October 15, 2017 On 2016-10-29 at 7:13 PM, ashman70 said: Just wanted to report back that running the New Permissions (Docker Safe) tool fixed my problem. Thanks for the help. Where do i find that? Quote Link to comment
BobPhoenix Posted October 15, 2017 Share Posted October 15, 2017 6 hours ago, Lappen71 said: Where do i find that? That is installed when the Community Applications plugin is installed. It is in the same location as the regular New Permissions under the Tools tab. Quote Link to comment
Squid Posted October 15, 2017 Share Posted October 15, 2017 3 minutes ago, BobPhoenix said: That is installed when the Community Applications plugin is installed. It is in the same location as the regular New Permissions under the Tools tab. Fix Common Problems. Quote Link to comment
BobPhoenix Posted October 15, 2017 Share Posted October 15, 2017 Just now, Squid said: Fix Common Problems. Opps! Thank you for correcting me. 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.