Jump to content

user0 with permissions 000


Pete

Recommended Posts

Mover stopped working. Always got a "skipping folder" message in the logs.

 

So I've looked into the mover script, and that script looks into /mnt/user0 and if it doesn't find a corresponding directory to move data to, it skips. Well, my /mnt/user0 directory has permissions set to 000, which means it is inaccessible!l Weird. And I can't change permissions even as root.

 

Any ideas how to fix that?

 

Pete

Link to comment

Syslog attached. After reboot and a manual trigger of the mover via the web interface.

 

And that is the content of the /mnt directory

 

/mnt# ls -al
/bin/ls: user0: No such file or directory
total 32
drwxr-xr-x 14 root   root  280 Feb 13 09:11 ./
drwxr-xr-x 18 root   root  380 Feb 13 09:11 ../
drwxrwxrwx  1 nobody users   4 Jan 29 04:27 cache/
drwxrwxrwx  4 nobody users  26 Jan 29 04:27 disk1/
drwxrwxrwx  3 nobody users  15 Jan  9 03:47 disk2/
drwxrwxrwx  2 nobody users   6 Dec 17 14:17 disk3/
drwxrwxrwx  2 nobody users   6 Dec 17 14:20 disk4/
drwxrwxrwx  2 nobody users   6 Dec 17 14:22 disk5/
drwxrwxrwx  2 nobody users   6 Dec 17 14:26 disk6/
drwxrwxrwx  2 nobody users   6 Dec 17 14:31 disk7/
drwxrwxrwx  2 nobody users   6 Dec 17 14:35 disk8/
drwxrwxrwx  2 nobody users   6 Feb  1 11:49 disk9/
drwxrwxrwx  1 nobody users   4 Jan 29 04:27 user/
d---------  1 root   root    0 Jan  1  1970 user0/

 

The reason for mover to skip tm/  IMO is the inability to access the user0 directory. But why is it set to permissions 000?

syslog.txt

Link to comment

Thanks for having a look into the syslog.

 

I've already seen this

FAT-fs (sdd1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

in the syslog. I assume that is the reason you suggested to repair the flash. As the server is in a remote location, I've used the following procedure instead of checking the flash in Mac or PC:

 

Stop the array.

unmount the flash drive.  (umount /dev/sdX1)

run fsck on the flash drive.  (dosfsck -av /dev/sdX1)  -a will automatically repair the file system and -v will be verbose.

reboot

 

This seems to have fixed that problem, at least the error message is gone.

 

Unfortunately this didn't fix the permission problem. user0 still has permissions 000 and mover is not working. Any other ideas?

 

Around the time the problem occurred, I've had a 1TB drive fail in the array. I've only had a spare 500MB drive at hand and as the dead drive didn't have any data on it, I've decided to replace the 1 TB with the 500 MB. UNRAID complained, that it had to be at least 1 TB, which ist correct, if I want to keep parity. Thus I recreated the array, keeping the data on all drives except the new 500MB drive, recreated the user share and rebuilt the parity. Could that be the reason for the permissions issues?

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...