The other thing that comes up once in a while is incorrect permissions on /
It seems you right !
Why that comes up once in a while ? Like it's a magic thing !
The other thing that comes up once in a while is incorrect permissions on /
It seems you right !
Why that comes up once in a while ? Like it's a magic thing !
I have no idea why this happens. But this is the clue in the auth log:
Jul 12 16:48:50 server sshd[14492]: fatal: bad ownership or modes for chroot directory component "/"
Thanks !
And how should I correct this ?
I'm little bit scarry of running chmod 755 / because I'm not sure it's a clean solution and I don't have the courage of making a system backup before, for the moment
That is the correct and only solution.
From the execution of chmod 755 /, I can log in and see my sharedfolder directory but I can't see its content, the sharedfolder appears empty.
Any idea ?
I've tried this :
OMV_SHAREDFOLDERS_DIR_ENABLED="YES" setting to /etc/default/openmediavault and then run:
omv-salt stage run prepare
omv-salt deploy run systemd
reboot
But didn't solve.
Should I understand that SFTP plugin definitively won't work/allow us to access local shared files from internet ?
What's the best way to do this with openmediavault ?
If you want to use the /sharedfolder/ feature, you need to set OMV-SHAREDFOLDERS_DIR_ENABLED="YES".
However, this only changed, if you find bind mounts to the shared folders in /sharedfolders/.
In any case you will find the shared folders with their absolute path /srv/dev-disk-by-label.....
Sorry I made a mistake, I had set 'YES'. I corrected my post.
But this didn't solve my problem.
I do not use that plugin, but it seems that the shared folders added to the service are mounted in /sftp. Correct? Have you looked there?
Yes, I have my shared folders mounted in /sftp and they appear empty.
Should I understand that SFTP plugin definitively won't work/allow us to access local shared files from internet ?
Of course it will and I use it for that. I would try uninstalling the plugin and install again and make sure the user has permissions to the content. Also, the sharedfolder dir does not need to be enabled and I actually wouldn't enable it.
I have the same problem on a fresh install of openmediavault.
user duplibackup is added to the group sftp-access.
with "Allow access to sftp-access group only" turned off, I can login as another user and this user has full acces to / but duplibackup cannot login.
with "Allow access to sftp-access group only" turned on, I get the following filezilla output:
Antwoord: fzSftp started, protocol_version=9
Opdracht: open "duplibackup@192.168.179.175" 222
Status: Using username "duplibackup".
Opdracht: Pass: **************
Fout: FATAL ERROR: Network error: Software caused connection abort
Fout: Kan niet verbinden met server
in auth.log
Nov 26 18:15:08 omvwilnis sshd[1812]: Accepted password for duplibackup from 192.168.179.131 port 56064 ssh2
Nov 26 18:15:08 omvwilnis sshd[1812]: pam_unix(sshd:session): session opened for user duplibackup by (uid=0)
Nov 26 18:15:09 omvwilnis sshd[1821]: fatal: bad ownership or modes for chroot directory component "/"
Nov 26 18:15:09 omvwilnis sshd[1812]: pam_unix(sshd:session): session closed for user duplibackup
I did not do any chmod's but these seem to be ok.
output of ls -l
lrwxrwxrwx 1 root root 7 nov 22 19:13 bin -> usr/bin
drwxr-xr-x 3 root root 4096 nov 23 20:27 boot
drwxr-xr-x 17 root root 3320 nov 26 18:13 dev
drwxrwxr-x 97 root root 4096 nov 26 17:10 etc
drwxr-xr-x 2 root root 4096 mrt 17 2020 export
drwxr-xr-x 2 root root 4096 feb 1 2020 home
lrwxrwxrwx 1 root root 35 nov 23 00:28 initrd.img -> boot/initrd.img-5.8.0-0.bpo.2-amd64
lrwxrwxrwx 1 root root 35 nov 22 19:13 initrd.img.old -> boot/initrd.img-5.4.0-0.bpo.4-amd64
lrwxrwxrwx 1 root root 7 nov 22 19:13 lib -> usr/lib
lrwxrwxrwx 1 root root 9 nov 22 19:13 lib32 -> usr/lib32
lrwxrwxrwx 1 root root 9 nov 22 19:13 lib64 -> usr/lib64
lrwxrwxrwx 1 root root 10 nov 22 19:13 libx32 -> usr/libx32
drwx------ 2 root root 16384 nov 22 19:12 lost+found
drwxr-xr-x 3 root root 4096 mrt 25 2020 media
drwxr-xr-x 2 root root 4096 mrt 25 2020 mnt
drwxr-xr-x 2 root root 4096 mrt 25 2020 opt
dr-xr-xr-x 235 root root 0 nov 26 18:11 proc
drwx------ 5 root root 4096 nov 23 18:36 root
drwxr-xr-x 30 root root 1100 nov 26 18:28 run
lrwxrwxrwx 1 root root 8 nov 22 19:13 sbin -> usr/sbin
drwxr-xr-x 3 root root 4096 nov 26 15:59 sftp
drwxr-xr-x 2 root root 4096 mrt 17 2020 sharedfolders
drwxr-xr-x 7 root root 4096 nov 22 20:14 srv
dr-xr-xr-x 13 root root 0 nov 26 18:11 sys
drwxrwxrwt 10 root root 200 nov 26 18:17 tmp
drwxr-xr-x 13 root root 4096 nov 22 19:23 usr
drwxr-xr-x 13 root root 4096 nov 23 19:30 var
lrwxrwxrwx 1 root root 32 nov 23 00:28 vmlinuz -> boot/vmlinuz-5.8.0-0.bpo.2-amd64
lrwxrwxrwx 1 root root 32 nov 22 19:24 vmlinuz.old -> boot/vmlinuz-5.4.0-0.bpo.4-amd64
I have several plugins installed:
openmediavault-backup 5.2.1
openmediavault-downloader 5.1
openmediavault-flashmemory 5.0.7
openmediavault-fail2ban 5.0.5
openmediavault-sftp 5.0.6
openmediavault-omvextrasorg 5.4.2
I am using OMV-version 5.5.17-3 (Usul).
The only commandline changes that I did was the installscript of omv-extras and the changes from openmediavault-flashmemory.
So I am pretty sure there is still a bug in the sftp plugin.
ryecoaaron Can you please give me some instructions that will help find the bug.
This is your problem:
Nov 26 18:15:09 omvwilnis sshd[1821]: fatal: bad ownership or modes for chroot directory component "/"
Fix it like this in a root shell:
chmod 755 /
So I am pretty sure there is still a bug in the sftp plugin.
ryecoaaron Can you please give me some instructions that will help find the bug.
Many, many people (including myself) use this plugin and don't have a problem. This is not a bug. 99.9% of the time, it is permissions. what is the output of: stat /
output of stat /
Bestand: /
Grootte: 4096 Blokken: 8 IO-blok: 4096 map
Apparaat: 821h/2081d Inode: 2 Koppelingen: 21
Toegang: (0775/drwxrwxr-x) UID: ( 0/ root) GID: ( 0/ root)
Toegang: 2020-11-23 00:28:44.249652593 +0100
Gewijzigd: 2020-11-26 15:45:36.834695509 +0100
Veranderd: 2020-11-26 15:45:36.834695509 +0100
Ontstaan: -
So this should probably indicate that a chmod 755 / would solve the problem, but how did this permission get wrong?
how did this permission get wrong?
Some installers set it incorrectly. My install script actually fixes it but I think there were a few ISOs that set it wrong.
Ah that's interesting, I installed from openmediavault 5.3.9-amd64 as I still had a burned CD with that iso.
After install I just updated with "update management"
I did not use the latest iso. Good lesson for me to remember: "always use the latest updates."
After chmod 755 / it works now.
Many thanks for the very quick help to ryecoaaron and gderf .
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!