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?

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.

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

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?

 

 

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 ?

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.

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

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.

I am synchronizing the files through SMB shares, not NFS.

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.

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.

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.

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

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 

Thanks but I wouldn't have a clue what to do, so I need some assistance if possible.

Have you tried running the "New Permissions" tool in the tools tab/menu?

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

Yes, I meant the one that has (Docker safe) underneath..

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.

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)

Just wanted to report back that running the New Permissions (Docker Safe) tool fixed my problem.

 

Thanks for the help.

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?

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.

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.

Just now, Squid said:

Fix Common Problems.

Opps! Thank you for correcting me.