[SOLVED] user share permission problems...

[tillkrueger]

i'm still on 5b7...running OSX Lion 10.7.1 (with the inherent NAS issues), and the unRAID array mounted as an SMB User Share...for the past few months since getting my unRAID up and running again after a 1 year down-time, i've often run into situation where i can't copy/paste/delete or synch files/folders, because of some permission problems of sorts...like right now, i'm trying to copy from my iMac's OSX System disk to a folder on my SMB unRAID share (trying to copy 300GB of timelapse photos)...whatever i do, i get this error:

"Items can’t be copied to “Timelapses” because you don’t have permission to read them."

 

i've tried to fix permissions via DiskUtil (found quite a few errors to fix and fixed them), mounted my unRAID disk in various ways (AFP, SMB), changed share settings in the unRAID web interface (public/private security models), and tried a few properties changes on my source disk (deleting and adding my user name to the permissions list), etc., all to no avail.

 

however, when i look for the folder i'm trying to copy to on the unRAID, and mount the disk share on my iMac, it allows me to copy the folder...whay is that? why will this only work via user-shares? i know i must be missing something very basic here, but at the moment it kind of eliminates the "flow-over" features of unRAID, since i have to manage all of the individual disks' size myself.

 

anyone have the answer?

 

i'm not that much of a command line person, and i've often run into my limits, but was kindly helped here on the boards...what to try when simple copy/paste actions won't be permitted?

[tillkrueger]

is my question so clueless that it warrants no replies, or is it one of those questions that have so many answers/possibilities, that there is no good way to begin troubleshooting?

 

i guess a simplified way of asking would be: if i can't write to a user-share, where do i start troubleshooting? and why would i get read permission errors when trying to copy to a user-share from my home directory?

[prostuff1]

is my question so clueless that it warrants no replies, or is it one of those questions that have so many answers/possibilities, that there is no good way to begin troubleshooting?

 

i guess a simplified way of asking would be: if i can't write to a user-share, where do i start troubleshooting? and why would i get read permission errors when trying to copy to a user-share from my home directory?

 

We need a syslog for a start.  Without that it is hard to guess.

 

Also, if you are running a beta now, I suggest updating to beta11 or 12a see if something in there fixes the issues.  Also run the new perm script from the utilities page after you upgrade and start fresh.

[Auggie]

Another thing to think about is: what user name and login did you create on unRAID and which one did you actually login as from OS X?  And have you always ensured you logged in with the same credentials to unRAID?  Have you been using "Recent Servers" to access previous connections or always connecting manually via the Cmd-K/menubar option?  Did you have your login "remembered" in your KeyChain?  Using "Recent Servers" or KeyChain will always use the login credentials you used for that session.  You may have to delete that login in your KeyChain to allow you to connect under a different user.

 

I noticed under v5 betas that individual user permissions are more strictly enforced.  I had "bookmarked" my FTP "login" to unRAID using a manually created user and noticed immediately that I couldn't access any files/folders that were uploaded via FTP through an SMB connection, where as under v4 I was able to.  If I wanted files/folders to be accessible by everyone I now have to ensure I log in as "root."

 

Usually when I get permissions errors, running the Permissions Utility in unRAID clears it up.

[tillkrueger]

here is the syslog.

 

Auggie, i lost track of the many ways i've mounted the unRAID as either a single user-share, or as individual disk-shares (to overcome my permission problems at times)...Lion has increased my confusion, as the NAS mechanism appears to have been changed and i had to resort to all sorts of terminal/telnet acrobatics that resulted in my at least being able to access unRAID again...but it's quite likely that along the way i may have done one thing as "root" and another as "till"...i thought the permissions for both users were equal, so it shouldn't matter, but obviously i'm not fully understanding the inner workings of users and permissions down to that level.

 

which utility will i need to run to try to fix permissions (and how), and how long will it likely take on about 25TB of data?...probably a long time, no?

 

syslog-2009-09-09.txt

[Auggie]

To run the unRAID Permissions utility, click on the UTILS tab, then click on NEW PERMISSIONS icon under the UPGRADE UTILITIES section.  Check on the "Yes I want to do this", and finally click on the START button.

 

My 28TB's took about 20-30 minutes to complete.

 

Going forward, you have to carefully review your SHARES tab and the specific security options you have set for AFP, NFS and/or SMB, and each of the individual User Access you have created.

 

I can't locate the document/description of what each level of Security mode (PUBLIC, SECURE, PRIVATE) provides and how it affects the files/folders, so I'm hoping someone else can provide an accurate description as I don't want to rely on my old "memory" on what I read regarding the differences, but you may want to set it to PUBLIC and then connect without using credentials so as to create all files/folders under root permissions (I believe).  Once you have everything accessible and working as you expect, only then start dabbling in connecting with different user credentials and experimenting with the Security mode and User Access settings.

[mbryanr]

I can't locate the document/description of what each level of Security mode (PUBLIC, SECURE, PRIVATE) provides and how it affects the files/folders, so I'm hoping someone else can provide an accurate description as I don't want to rely on my old "memory" on what

Was it the "Overview"?

http://lime-technology.com/forum/index.php?topic=7047.0

[tillkrueger]

started the "New Permissions" script and am waiting for it to complete...will then take another look at my export settings to see whether i missed anything...but if i understand you correctly, Auggie, then i should have no problems writing to an SMB or AFP user-share, if all export settings are configured correctly, right? (otherwise, what would be the point!)

 

BTW, is there a way to check progress on the "New Permissions" script? kinda creepy how it just sits there and says nothing...an hour and counting...

[Auggie]

The script appears to provide status updates as each individual drive is completed. The updates are displayed on the Permissions Utility page.

[Auggie]

Was it the "Overview"?

http://lime-technology.com/forum/index.php?topic=7047.0

 

No, i read up on the v5 security models somewhere else, but this certainly will do for now and I will bookmark it!

[tillkrueger]

hmmm...half a day later there was still no update posted to the browser window...i should add that i am using that nice looking CSS theme that's posted/linked-to here on the customizations boards...forgot the name. (not sure that it makes a difference.)

anyway, no change in the read-permissions error or other issues with deleting/moving/copying files.

 

what's the Terminal command to fix all permissions on the unRAID server?

 

time to hit the sack here in Germany...g'nite!

thanks for helping, so far, folks!!

[prostuff1]

hmmm...half a day later there was still no update posted to the browser window...i should add that i am using that nice looking CSS theme that's posted/linked-to here on the customizations boards...forgot the name. (not sure that it makes a difference.)

anyway, no change in the read-permissions error or other issues with deleting/moving/copying files.

It might not be displaying the output, not sure.

 

what's the Terminal command to fix all permissions on the unRAID server?

type: newperms /mnt/diskX and replace x with a drive number

 

[tillkrueger]

thx...will try it manually then, one disk at a time, just to be sure...

[tillkrueger]

seems to work without problems via terminal, and at least i can see roughly how long it takes...some 2TB disks (98% full) take about 20mins, while another (85% full) only took maybe 2mins...curious...all are WD Green drives, and all are on the same PCIe cards (Supermicros, i think).

 

only disk 6 gives me problems so far, as it reports back as "Read-only file system"...could it be the cause of write-errors to *anywhere* on the unRAID user-share?

 

another thing i realized is that i Telnet into unRAID, out of habit, as "root"...when the newperms command executes the "chown -R nobody:users /mnt/diskX" part, does it mean that it changes ownership to "nobody", or am i having problems because i mount the unRAID user-share as the "Till" user, but am changing permissions on the unRAID to "root" while logged in as such, and executing the newperms command as the root user?

 

you can tell i'm a terminal newbie, no?

[prostuff1]

seems to work without problems via terminal, and at least i can see roughly how long it takes...some 2TB disks (98% full) take about 20mins, while another (85% full) only took maybe 2mins...curious...all are WD Green drives, and all are on the same PCIe cards (Supermicros, i think).

The number of files makes a huge difference.  I have disks that a nearly identical in percetn full but one is TV Shows and another is DVD.iso files.  The TV shows drive takes a much longer amount of time than does the DVD.iso disk.

 

only disk 6 gives me problems so far, as it reports back as "Read-only file system"...could it be the cause of write-errors to *anywhere* on the unRAID user-share?

you are probably going to have to run a reiserfsck --check on that disk.  It probably has file system corruption on it.  There should be instructions in the wiki and you can get to that via the link in my signature.

 

another thing i realized is that i Telnet into unRAID, out of habit, as "root"...when the newperms command executes the "chown -R nobody:users /mnt/diskX" part, does it mean that it changes ownership to "nobody", or am i having problems because i mount the unRAID user-share as the "Till" user, but am changing permissions on the unRAID to "root" while logged in as such, and executing the newperms command as the root user?

The newperms script does set the permission and ownership to nobody for the users group.  Running this as root will make no difference.  Mounting the user share as till will make no "real" difference as till is part of the users group.  If you log into a telnet session as root and do something (move a file, create one, etc) then you have "screwed up" the permissions for that file.  root is part of the root group, not users.  Therefore if you go and try and access that file from a user share where till has mounted it and is part of the users group it should/might fail.  I am a little fuzzy on what exactly will happen, but I know from experience if you bypass the smb user shares and move files using MC or the like then the permissions will be wrong as everything is done as root:root and not till:users or nobody:users.  If root:root moves it then the user root and the users in the root group can mess with the file.

 

you can tell i'm a terminal newbie, no?

We were all terminal newbies at once.

[tillkrueger]

still, thanks for hanging in there with me, prostuff!

 

yup, disk6 seems to have some errors and corruptions...reiserfsck came back with this:

 

Comparing bitmaps..vpf-10640: The on-disk and the correct bitmaps differs.

Bad nodes were found, Semantic pass skipped

199 found corruptions can be fixed only when running with --rebuild-tree

###########

reiserfsck finished at Tue Sep 13 09:30:24 2011

###########

 

so, i'm off to to a tree rebuild...it seems that i just went through this not too long ago, but maybe that was on a different disk...will have to research and then be back.

 

[tillkrueger]

where does reiserfsck write the log to?

 

anyway, the rebuilding of the file/directory tree finished with about a thousand files found to be faulty, if i remember correctly...oh wait! here is the terminal output:

 

Looking for lost files:5 /sec

vpf-10670: The file [5 12656] has the wrong size in the StatData (0) - corrected to (12339003392)

vpf-10680: The file [5 12656] has the wrong block count in the StatData (24120326) - corrected to (24096792)

Flushing..finished6, 207 /sec

Objects without names 1082

Empty lost dirs removed 12

Dirs linked to /lost+found: 91

Files linked to /lost+found 991

Pass 4 - finisheddone 147001, 202 /sec

Deleted unreachable items 12

Flushing..finished

Syncing..finished

###########

reiserfsck finished at Tue Sep 13 14:46:19 2011

###########

 

the lost+found directory showed "0 items" though...i'm still left with one of my DVD folders with about 90 disks in it, taking up about 600GB, so maybe many of those are still complete...but time will tell what the damage was.

 

i still can't delete some empty folders because of permissions problems, so does that mean the disk may be beyond repair? probably best to be safe and try to exchange it on warranty, or to replace it with a new one otherwise, no?

 

 

[prostuff1]

where does reiserfsck write the log to?

 

anyway, the rebuilding of the file/directory tree finished with about a thousand files found to be faulty, if i remember correctly...oh wait! here is the terminal output:

 

Looking for lost files:5 /sec

vpf-10670: The file [5 12656] has the wrong size in the StatData (0) - corrected to (12339003392)

vpf-10680: The file [5 12656] has the wrong block count in the StatData (24120326) - corrected to (24096792)

Flushing..finished6, 207 /sec

Objects without names 1082

Empty lost dirs removed 12

Dirs linked to /lost+found: 91

Files linked to /lost+found 991

Pass 4 - finisheddone 147001, 202 /sec

Deleted unreachable items 12

Flushing..finished

Syncing..finished

###########

reiserfsck finished at Tue Sep 13 14:46:19 2011

###########

 

the lost+found directory showed "0 items" though...i'm still left with one of my DVD folders with about 90 disks in it, taking up about 600GB, so maybe many of those are still complete...but time will tell what the damage was.

 

i still can't delete some empty folders because of permissions problems, so does that mean the disk may be beyond repair? probably best to be safe and try to exchange it on warranty, or to replace it with a new one otherwise, no?

 

 

Now that it is repaired run the newperms script on the disk again.

[tillkrueger]

ok, after running the newperms script on the repaired disk, i am now able to delete the empty folder i wasn't able to delete before...i also now see the contents of the lost+found folder that showed as "0 items" before running newperms, and it now shows me over 1000 folders, which - much to my dismay - contain bits and pieces of what were about 120 pristine DVD movies...looks like nary a one made it through unharmed...too much work to try to figure out how to piece them back together...will have to re-rip at some point when i don't have anything better to do...too bad, though.

 

thanks for your help...i'm off to bed.

 

oh! i just did one more test of copying a random file to my unRAID user-share, and lo and behold: i can now copy to the "bulk" disk, finally being back to using unRAID as it was intended to be used (rather than managing all folders and "overflow" manually).

 

maybe it was worth losing a disk over that, and learning a few new tricks in terminal.

[prostuff1]

ok, after running the newperms script on the repaired disk, i am now able to delete the empty folder i wasn't able to delete before...i also now see the contents of the lost+found folder that showed as "0 items" before running newperms, and it now shows me over 1000 folders, which - much to my dismay - contain bits and pieces of what were about 120 pristine DVD movies...looks like nary a one made it through unharmed...too much work to try to figure out how to piece them back together...will have to re-rip at some point when i don't have anything better to do...too bad, though.

 

thanks for your help...i'm off to bed.

 

oh! i just did one more test of copying a random file to my unRAID user-share, and lo and behold: i can now copy to the "bulk" disk, finally being back to using unRAID as it was intended to be used (rather than managing all folders and "overflow" manually).

 

maybe it was worth losing a disk over that, and learning a few new tricks in terminal.

glad you got it worked out.  The corruption was probably the thing that was causing the headaches for you.  The newperms script could not run on a disk that had the corruption.  You would need to fix that before it would work.

 

Your not the first I have seen this happen to.  A customer of mine had a drive with corruption on it.  After I fixed that a ran the newperms script on the disk was fine afterwards.