SFTP / File Permissions

Hi folks,

I installed the latest version of OpenSSH today so that I could use SFTP from Transmit on my iPad to access the Drobo (5N). Unfortunately this does not work for me. I am able to connect to the Drobo using the user accounts I have set up, but cannot access any of the files in any of my shares.

ssh user@ip user@ip's password: $ cd /mnt/DroboFS/Shares/BigData $ $ cd Media -sh: cd: can't cd to Media $ ls -la Media ls: can't open 'Media': Permission denied

I’m logging in as the “Admin” user in the Dashboard (though I’ve change the username to something else).

If I sudo su I’m able to access the files:

$ sudo su Password: $ ls -la /mnt/DroboFS/Shares/BigData/Media drwx--S--- 24 root root 4096 Jan 22 13:09 . drwxrwxrwx 16 root root 4096 Jan 26 09:51 .. -rwx------ 1 root root 14340 Jan 21 14:17 .DS_Store [snip]

But obviously I can’t do that from SFTP.

I tried logging in as root directly, but cannot (I do not know the password; the password assigned to the Admin user does not work).

How can I use SFTP from my iPad to access the files in my shares?


That is on purpose. Enabling root logins on an internet-accessible service is asking for a lot of trouble. If you know what you are doing, you can enable the root account and assign a password to it, but I advise strongly against it. Especially if you are running your SSH server on port 22.

How about changing the permissions of those files?

Let’s say that you want to give read-only access to all files inside Media to all users:

sudo -s
cd /mnt/DroboFS/Shares/BigData/Media
find . -type f -exec chmod -R a+r {} \;
find . -type d -exec chmod -R a+rx {} \;

This should do the trick.


Thank you very much for the reply!

This NAS is not accessible from the internet. It is behind a firewall / NAT. So logging in with root is of less of a concern, though I still have no specific desire to do it. Ideally I would simply grant the appropriate permissions to my dashboard created user account.

Changing the permissions seems like a reasonable approach. I was just afraid I might cause trouble with the Drobo’s native functions by mucking with the file system.

I used to do quite a bit with Linux but unfortunately I’ve let my skills go unused for some time and as such they’ve dulled a bit. I’m trying to work out exactly what each of your commands does, in hopes of modifying them to best suit my needs. If I understand correctly…

The first one: finds all files (within Media) and changes the permissions for everyone (a) to read-only (+r)
The second one: finds all directories (within and including Media) and changes the permissions for everyone (a) to read-only (+r) and execute (+x – which iirc is required to cd into the directory?)

What I would prefer to do, if possible, is give one specific dashboard user read+write to all files and directories. Again, I’m a little rusty, so any additional help would be appreciated… Would it be appropriate to create a new group that contains both the root user and my dashboard user, then:

sudo su cd /mnt/DroboFS/Share/BigData chgrp mygroup Media chmod -R g+rwx Media

Or, since root already has access… being the owner of the files/directories (plus, it is root)… can I exclude root from the group and simply have it contain my one dashboard user?

Please let me know. Thanks!


EDIT: Just realizing this would also set all files to executable as well, which it probably why you split it into two commands.

It seems your permissions are already mucked up. The normal permissions are 644 for files and 755 for directories. I’m not entirely sure it came to that. Do you happen to have Plex installed on your Drobo?

Yep, you are quite right. The ‘a’ means it will set the bits for owner, group, and others.

That is the permission model I run on my device. I create a new group for each share (e.g. ‘public’ for ‘Shares/Public’), and then I add each user to their respective shares’ groups.

After that the code goes like this:

chgrp -R <share group> <Share Directory>
find <Share Directory> -type d -exec chmod -R g+rwxs {} \;
find <Share Directory> -type f -exec chmod -R g+rw {} \;

Notice the +s on folders? That sets the setgid bit, which will ensure that all future files and directories created later on will inherit the group unless manually changed.

The downside of this approach is that users and groups created outside of Dashboard are reset on boot, which means you have to recreate them every time you reboot the device.

Sure, although this might break a few DroboApps. I suggest giving it a test with a couple of directories before switching everything over.


Worked perfect, thanks!

And no, no Plex, but I do have BT Sync installed and running.

The groups being reset on reboot is a real bummer… Any way around that? I almost never reboot this thing, but that means I’m even more likely to forget to recreate the group next time I do and then I’ll be scratching my head as to why I can’t access my files.

You could create a pseudo-DroboApp that will recreate the groups (hopefully with the same GID), re-add the users to the groups, and refresh the permissions on the files/directories. DroboApps run on boot, so that should be enough to make the change permanent as long as you have DroboApps enabled and don’t clear your diskpack.

To create a pseudo-DroboApp you just need to create a new directory under DroboApps (call it mygroups, for example), and add a service.sh shell script in it. That script is supposed to have a specific structure, which you can learn about in the SDK: ftp://updates.drobo.com/droboapps/development/SDK-2.1.zip

If you put some effort in it, you’ll even be able to use the Drobo Dashboard to “start” and “stop” your pseudo-DroboApp, which could be used to regenerate/refresh users, groups, and permissions after a new user is added using the Dashboard.

All of this is way above my head, but I think it is exactly my problem regarding my proftpd folder inaccessibility problem.

Can I Do something in the dashboard to have every files on the Drobo in read-only for everyone instead of the command line you are proposing?

(just linking related post)

Sorry, I don’t think so.