Confused by SMB on unRaid.

 

I've been having sporadic issues with windows file manager (windows 10) complaining that I don't have rights to a directory.  It is not consistent and may work for a while then not.  Is there a configuration somewhere that specifies user access levels for directories by share?  Am I on the right track with this?  In the share for SMB, Security is set at Public, so seems like there should be no issue.  

 

I've moved my backup software to access the server in FTP mode (ProFTPd) and that appears to be working with no issues.

 

Thanks in advance...

Does it change depending upon the file / folder being accessed?  IE: Does one particular file/folder consistently give permission errors while others don't?

Its been very hard to diagnose. At first I thought it was a specific share, but sometimes it will work and sometimes it won't.  Sometimes it will work at the top directory of a share but not the lower directories.  I don't have ANY problem accessing the share from the console.  For instance, I can access the Cache share from the console (/mnt/user/cache) and copy/create/delete anything I want.  But I I navigate to the SMB share in windows explorer and try to do something "you need permission to perform this action" is the response.  Here's an example.

 

Windows Explorer (windows 10)

- Navigate to server/cache share

- Left-click new folder (you need permission)

- go to telnet, cd /mnt/user/cache, mkdir web, directory created

- THEN go back to explorer, navigate to server/cache/web, left-click create new folder, new folder created.

 

I've had the same thing happen on other shares.

You'd need to post up the output of

ls -al /mnt/user/cache

 

If you're creating and manipulating directories and files at the command line, logged in as root, then you will have problems when trying to access them as any other user, which is the case when you use SMB. There are things you can do to mitigate this, the easiest being to type

user nobody

after you've logged in as root.

If you're creating and manipulating directories and files at the command line, logged in as root, then you will have problems when trying to access them as any other user, which is the case when you use SMB. There are things you can do to mitigate this, the easiest being to type

user nobody

after you've logged in as root.

Depends upon the permissions of the file. Default root permissions will give world RW access

Sent from my SM-T560NU using Tapatalk

I agree but take this as an example. 

# ls -l
total 0
-rw-r----- 1 nobody users  10 Feb 22 00:40 a
# cp a b
# ls -l
total 0
-rw-r----- 1 nobody users  10 Feb 22 00:40 a
-rw-r----- 1 root   root   10 Feb 22 00:45 b

Result is that file b can't read or written by Windows, while file a can.

3 hours ago, Squid said:

You'd need to post up the output of

ls -al /mnt/user/cache

 

Interesting, it states that the directory does not exist?!?

root@HunterNAS:/# ls -al /mnt/user/cache
/bin/ls: cannot access '/mnt/user/cache': No such file or directory
root@HunterNAS:/# cd /mnt/user
root@HunterNAS:/mnt/user# cd cache
-bash: cd: cache: No such file or directory
root@HunterNAS:/mnt/user# ls
DocArchive/   README        cachebackup/           docs/             installgl.debug  movies/    usr/
Dropbox/      UPGRADING     changelog              etc/              installgl.sh*    music/     web/
ISO\ Files/   appdata/      convert_to_2.0.pl*     ftp-data/         jwhbackup/       pictures/
LICENCE       archives/     create_server_key.sh*  gcp/              lib/             site/
My\ Backups/  autoinst.sh*  dev/                   glftpd.conf.dist  lib64/           sitebot/
Pydio/        bin/          docker.img             home\ movies/     libcopy.sh*      tv/
root@HunterNAS:/mnt/user# cd cache
-bash: cd: cache: No such file or directory
root@HunterNAS:/mnt/user#

Yet, windows can see the directory...

 

I agree but take this as an example. 

# ls -ltotal 0-rw-r----- 1 nobody users  10 Feb 22 00:40 a# cp a b# ls -ltotal 0-rw-r----- 1 nobody users  10 Feb 22 00:40 a-rw-r----- 1 root   root   10 Feb 22 00:45 b

Result is that file b can't read or written by Windows, while file a can.

Because in both cases the world readable permission isn't set so only the owner and group can read it.

Sent from my SM-T560NU using Tapatalk

Interesting, it states that the directory does not exist?!?

root@HunterNAS:/# ls -al /mnt/user/cache/bin/ls: cannot access '/mnt/user/cache': No such file or directoryroot@HunterNAS:/# cd /mnt/userroot@HunterNAS:/mnt/user# cd cache-bash: cd: cache: No such file or directoryroot@HunterNAS:/mnt/user# lsDocArchive/   README        cachebackup/           docs/             installgl.debug  movies/    usr/Dropbox/      UPGRADING     changelog              etc/              installgl.sh*    music/     web/ISO\ Files/   appdata/      convert_to_2.0.pl*     ftp-data/         jwhbackup/       pictures/LICENCE       archives/     create_server_key.sh*  gcp/              lib/             site/My\ Backups/  autoinst.sh*  dev/                   glftpd.conf.dist  lib64/           sitebot/Pydio/        bin/          docker.img             home\ movies/     libcopy.sh*      tv/root@HunterNAS:/mnt/user# cd cache-bash: cd: cache: No such file or directoryroot@HunterNAS:/mnt/user#

Yet, windows can see the directory...
 

Sorry meant /mnt/cache

Sent from my SM-T560NU using Tapatalk

Sorry, I should have seen that too...

root@HunterNAS:/# ls -al /mnt/cache
total 20971536
drwxr-xr-x  1 nobody users          40 Feb 21 21:00 ./
drwxr-xr-x 15 root   root          300 Feb 21 18:18 ../
drwxrwxrwx  1 nobody users         330 Feb 21 03:00 appdata/
-rw-rw-rw-  1 nobody users 21474836480 Feb 21 22:39 docker.img
drwxrwxr-x  1 nobody users           0 Feb 21 17:31 web/
root@HunterNAS:/#

 

Here's the whole Shares/User directory

root@HunterNAS:/mnt/user# ls -al
total 20971836
drwxr-xr-x  1 nobody users          40 Feb 21 21:00 ./
drwxr-xr-x 15 root   root          300 Feb 21 18:18 ../
drwxrwxrwx  1 nobody users           6 Jan 16 16:02 DocArchive/
drwxrwxrwx  1 nobody users          24 Jul  2  2016 Dropbox/
drwxrwxrwx  1 nobody users        4096 Feb 20 18:14 ISO\ Files/
-rw-r--r--  1 nobody users        1381 Mar 31  2015 LICENCE
drwxrwxrwx  1 nobody users         327 Feb 21 21:00 My\ Backups/
drwxrwxrwx  1 nobody users         132 Apr 11  2016 Pydio/
-rw-r--r--  1 nobody users        3620 Mar 31  2015 README
-rw-r--r--  1 nobody users       29992 Mar 31  2015 UPGRADING
drwxrwxrwx  1 nobody users         330 Feb 21 03:00 appdata/
drwxrwxrwx  1 nobody users        4096 Feb 21 17:35 archives/
-rwxr-xr-x  1 nobody users         113 Mar 31  2015 autoinst.sh*
drwxr-xr-x  1 nobody users        4096 Mar 31  2015 bin/
drwxrwxrwx  1 nobody users         121 Feb 21 17:35 cachebackup/
-rw-r--r--  1 nobody users      138213 Mar 31  2015 changelog
-rwxr-xr-x  1 nobody users        4282 Mar 31  2015 convert_to_2.0.pl*
-rwxr-xr-x  1 nobody users        2061 Mar 31  2015 create_server_key.sh*
drwxr-xr-x  1 nobody users          57 Mar 31  2015 dev/
-rw-rw-rw-  1 nobody users 21474836480 Feb 21 22:39 docker.img
drwxr-xr-x  1 nobody users           6 Mar 31  2015 docs/
drwxr-xr-x  1 nobody users         137 Mar 31  2015 etc/
drwxr-xr-x  1 nobody users         145 Mar 31  2015 ftp-data/
drwxr-xr-x  1 nobody users          74 Mar 31  2015 gcp/
-rw-r--r--  1 nobody users        7563 Mar 31  2015 glftpd.conf.dist
drwxrwxrwx  1 nobody users          46 Feb 15 03:00 home\ movies/
-rw-r--r--  1 nobody users        5330 Mar 31  2015 installgl.debug
-rwxr-xr-x  1 nobody users       53724 Mar 31  2015 installgl.sh*
drwxrwxrwx  1 nobody users          99 Jan 14 20:12 jwhbackup/
drwxr-xr-x  1 nobody users          30 Mar 31  2015 lib/
drwxr-xr-x  1 nobody users          42 Mar 31  2015 lib64/
-rwxr-xr-x  1 nobody users        6702 Mar 31  2015 libcopy.sh*
drwxrwxrwx  1 nobody users         160 Feb 21 00:00 movies/
drwxrwxrwx  1 nobody users        8192 Feb 20 21:41 music/
drwxrwxrwx  1 nobody users          94 Feb 20 15:00 pictures/
drwxr-xr-x  1 nobody users           6 Mar 31  2015 site/
drwxr-xr-x  1 nobody users          77 Mar 31  2015 sitebot/
drwxrwxrwx  1 nobody users         286 Feb 21 12:05 tv/
drwxr-xr-x  1 nobody users          42 Mar 31  2015 usr/
drwxrwxr-x  1 nobody users           0 Feb 21 17:31 web/
root@HunterNAS:/mnt/user#

I'm not sure why there's a docker.img and /appdata are in this directory (and current date/time) as I have that setup to backup elsewhere.  The destination share in settings for appdata backup/restore is cachebackup/current/...and that directory is full of current files...

6 hours ago, jeffreywhunter said:

I'm not sure why there's a docker.img and /appdata are in this directory (and current date/time) as I have that setup to backup elsewhere.

 

Because they are in /mnt/cache they will show up in /mnt/user as well.

You really should turn off your disk shares.

 

Can you give us a good explanation of why you think you need disk shares and user shares both?

 

I never use disk shares myself.

Don't use disk shares.  How do you turn them off? 

4 minutes ago, jeffreywhunter said:

How do you turn them off?

Settings, Global share settings.

I've been there before, guess I didn't connect that (I tend to leave default settings).  I noticed another setting.  

 

Tunable (enable Direct IO): Experimental: If set to Yes then mount User Share file system with FUSE direct_io mount option. This will increase write performance but might possibly decrease read performance. Auto selects No.

 

Has anyone used this to improve performance?  Has it worked well?

 

Are there any other DEFAULT settings that one should consider differently?