Beiträge von NAS-i-Goreng

Zitat von Zonk

Hi

OMV 2.2.14 on bananapi worked fine since a couple of years with Windows clients. Now I have tried to access a share with Linux Mint 18.3 but it is always denied.

...I can browse through the subfolders but I'm not able to read or write on it. On right click the filemanager shows: owner: root but everything is grey, so that I cannot change anything

The filemanager shows no permissions for reading or writing.

I read Windows there somewhere...

Could it have to do w. the file format?

I had a vFAT formatted USB stick and since this doesn't fit into the Linux file permissions system, the owner is always root and not much other permission info showed up.

This looks very similar to this. Are you trying to access NTFS/FAT formatted files?

Hello,

This might be a bit "texty"...

I re-formatted a USB stick that was formerly mounted under /srv/device-by-label-USB.

To format it with mkfs (from vFAT to ext4), I unmounted it, then carried out the formatting.

With this I also gave it a new label. It's not called USB-0.

After that I wanted to mount it again- but where? It is recognised as /dev/sdd1..

So did a re-start to see where it would automatically mount- and found it under /dev/disk-by-label/USB-0- not exactly a mount point, is it?

Looked into the /etc/fstab and to mz surprise the old label was still there to be mounted in the old place.

No new entry was made.

I could even access the stick (using Nemo) via its old path /srv/disk-by-label-USB.

Since this is incorrect, I modified the fstab, removed the old entry and replaced it with the new info and re-started OMV.

Now USB-0 does show up under /srv/... but I had to delete the previous folder (.../USB) manually = OMV added the old label+path to the /etc/fstab again!

What's going on here?

I would expect USB sticks to mount under /media or along with other drives under /srv

What's the default behaviour of OMV and are there any recommendations or best practice advice on ad-hoc removable storage?

PS: Been working from the command line, prefer it that way as I still got some issues with the browser not automatically using https for access, so GUI is 2nd choice.

Yes, this is meant to create a jail for specific users so I can assign each user a specific space and keep the rest of the system in the background (number/names of other users etc.)

Yes shared folder creation does not set permissions but it somehow goes together when you do this.

Zitat von macom

What do you mean with "logs on". Using ssh, smb, nfs?

Oops, sorry, should have clarified: sftp via a file explorer (Nemo in this case).

Hello,

Maybe this is straight forward:

When you define a shared folder in the GUI, you specify the location of a shared folder.

Lets say this folder is /srv/device-by-label-A/USERS/userA and userA logs on.

User A can then also view any content above his shared directory (so he can see everything in /srv/device-by-label-A/USERS).

The GUI does not seem to provide a way, or does it?

I could chown all higher directories to e.g. root and chmod 0700 but is there a better way?

Hello,

I've created a scheduled a daily rsync job to backup/mirror one drive onto the second.

But there seem to be two issues with it:

1. It's not working. It doesn't seem to be carried out consistently (but I will need to monitor this further)

2. I cannot see this job in /etc/crontab.

Now, according to this thread, OMV does not use crontab but instead "creates entries in the appropriate /etc/cron folder".

I don't even have such a folder. All that is listed under C in the /etc is this:

ca-certificates, ca-certificates.conf, ca-certificates.conf.dpkg-old, calendar, chrony, collectd, console-setup, cron-apt, cron.d, cron.daily, cron.hourly, cron.monthly, cron.weekly, crontab (and it's not in e.g. cron.daily either).

So, can I just fill crontab "as usual" instead, just to get it working (haven't tried so I won't mess up the system)?

Where should one be able to confirm the scheduled job from the GUI?

Ok, so this one I can now answer myself after quite some time invested.

But the reason was „simple“: A vFAT formatted USB stick doesn’t listen to any nonUnix permission settings.

Hence it is always mounted as „root“.

Only way out is to format it in a different format.

It does leave the problem of: How do you interconnect with Windows-created USB sticks as a non-root user?

But that’s a general Linux, not an OMV issue...

Hello,

Could someone perhaps decipher this error message below?

It comes up when I specify a shared folder under "access rights management"-> "shared folders".

sharedfolder_mount_units_systemctl_daemon_reload

Function: module.run Name: service.systemctl_reload

Result: False

Comment: No function provided.

Started: 13:34:33.095778

Duration: 1.945 ms Changes:

This particular share also appears as "referenced: no" in the GUI.

Got it. Thanks!

Hm yes, I guess this incompatibility might be the reason.

While searching for a solution, I remember now that I had a similar issue under Mint.

Solution: Just tested it and logged in as 'root' I can create and delete files and folders conveniently via Nemo.

Ok, that seems this one solved/answered then.

I should mark it as solved but can't see how, so I'll modify the topic header.

Update:

Yes this is a permissions issue.

I mounted another drive (SATA HDD, EXT4) and the user can get full access, can create & remove folders etc.

It's the stick that is not cooperating.

Hm yes /srv/. That was a typo.

I also mistook the device for a folder as it appeared as a folder in my file explorer...

In the GUI I tried it both ways specifying an existing folder as a shared folder as well as specifying a non-existent one expecting OMV to create it. None of these methods work and I suspect it has to do with permissions.

ls -l /srv/dev-disk-by-label-USB1/TEST 

returns that owner and group are 'root'. For some reason Linux is always mounting USB sticks with root ownership/permissions.

chown -R testuser:users /srv/dev-disk-by-label-USB1/TEST 

(it is a folder now, not a device) returns (with and w.o the recursive option):

chown: changing ownership of /srv/dev-disk-by-label-USB1/TEST/subfolder1/subfolder2: Operation not permitted

What confuses me is that I am actually doing this as 'root'.

Same here.

Did you solve it eventually?

This is what I get (short version, containing only "Result: false" operations).

At the bottom is the summary of executed operations with location references but I cannot match those with the error messages- nor can I make sense of most of them.

OMV\ExecException: Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C.UTF-8; omv-salt deploy run nginx 2>&1' with exit code '1': debian:

----------

ID: prereq_nginx_certificates

Function: salt.state

Result: False

Comment: Run failed on minions: debian

Started: 17:04:48.330492

Duration: 2539.739 ms

Changes:

debian:

----------

ID: remove_ssl_certificates_key

Function: module.run

Name: file.find

Result: False

Comment: No function provided.

Started: 17:04:48.931564

Duration: 2.011 ms

Changes:

----------

ID: monitor_nginx_service

Function: module.run

Name: monit.monitor

Result: False

Comment: No function provided.

Started: 17:04:52.968004

Duration: 1.82 ms

Changes:

Summary for debian

------------

Succeeded: 6 (changed=4)

Failed: 2

------------

Total states run: 8

Total run time: 4.592 s in /usr/share/php/openmediavault/system/process.inc:182

Stack trace:

#0 /usr/share/php/openmediavault/engine/module/serviceabstract.inc(60): OMV\System\Process->execute()

#1 /usr/share/openmediavault/engined/rpc/config.inc(167): OMV\Engine\Module\ServiceAbstract->deploy()

#2 [internal function]: Engined\Rpc\Config->applyChanges(Array, Array)

#3 /usr/share/php/openmediavault/rpc/serviceabstract.inc(123): call_user_func_array(Array, Array)

#4 /usr/share/php/openmediavault/rpc/serviceabstract.inc(149): OMV\Rpc\ServiceAbstract->callMethod('applyChanges', Array, Array)

#5 /usr/share/php/openmediavault/rpc/serviceabstract.inc(588): OMV\Rpc\ServiceAbstract->OMV\Rpc\{closure}('/tmp/bgstatusEu...', '/tmp/bgoutputOq...')

#6 /usr/share/php/openmediavault/rpc/serviceabstract.inc(159): OMV\Rpc\ServiceAbstract->execBgProc(Object(Closure))

#7 /usr/share/openmediavault/engined/rpc/config.inc(189): OMV\Rpc\ServiceAbstract->callMethodBg('applyChanges', Array, Array)

#8 [internal function]: Engined\Rpc\Config->applyChangesBg(Array, Array)

#9 /usr/share/php/openmediavault/rpc/serviceabstract.inc(123): call_user_func_array(Array, Array)

#10 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod('applyChangesBg', Array, Array)

#11 /usr/sbin/omv-engined(537): OMV\Rpc\Rpc::call('Config', 'applyChangesBg', Array, Array, 1)

#12 {main}

Thanks.

That solved it.

Added the user to the ssh group and I can access the home folder via Nemo easily.

However, it is the complete home folder. I‘d prefer to limit this a bit further so it’s just less complex when used as a simply file share/dropbox.

I‘d mark this one as solved as I‘ve just opened another thread on trying to do this with a USB stick as a test- before mounting my real backup drives.

USB mount

Hello,

I‘m testing OMV- carefully and not with my existing backup disks.

So connected a USB stick with existing data on it, vFat formatted.

It seems to go under /src/dev-by-label-USB1 also /dev/sdd1.

But it doesn’t come under /home/media as usual.

When ai want to add it as a shared folder, I get „failed to set file group to 'users‘ for '/src/dev-disk-by-label-USB1/test/'

So no suitable permissions? I am logged in as „admin“ in the GUI.

Chown via terminal „chown -R testuser:users /dev/sdd1 does not return any errors though.

The outcome I hope for is this:

Make the space on this USB stick available to one specific user and this should be the only file/path this user can rwx. Nothing else should be rwx.

Update on this:

Yes I can get the GUI via https now. But with two "hiccups":

1. One can still use https on port 80 for a plain user, not for admin login.

2. I cannot force a secure connection. If I activate this option, I get a long error message. The one that I filtered out were the ones listed below.

Could anyone interpret these perhaps?

ID: prereq_nginx_certificates

Function: salt.state

Result: False

Comment: Run failed on minions: debian

Started: 20:52:33.401008

Duration: 2357.754 ms

Changes:

ID: remove_ssl_certificates_key

Function: module.run

Name: file.find

Result: False

Comment: No function provided.

Started: 20:52:34.036121

Duration: 1.454 ms

Changes:

ID: monitor_nginx_service

Function: module.run

Name: monit.monitor

Result: False

Comment: No function provided.

Started: 20:52:37.755985

Duration: 1.652 ms

Changes:

Hello,

I'm assuming this may be a mounting problem but I'm not sure.

Got an error message:

ID: sharedfolder_mount_units_systemctl_daemon_reload

Function: module.run

Name: service.systemctl_reload

Result: False

Comment: No function provided.

Started: 18:55:59.185075

Duration: 1.976 ms

Changes:

This occurred after I added a USB stick, vFAT formatted, and it wouldn't mount it via the GUI.

So I went to the command line and after that it showed as mounted in the GUI.

Yet after restarting the machine, I get a sanity confirmation and the above error message is the result of applying the changes. So revered it and the sanity message went.

The USB stick however still shows as a mounted drive with volume data in the GUI.

Am I on the right path here...?!?

Thanks.

This will hopefully help.

I created a separate thread on the HTTPS issue, just to keep topics separate (hope that helps...): No HTTPS thread

So guess that one is solved, thanks for the help

Hi all,

I can’t get to the GUI over HTTPS.

Tried some browsers and even with add-ons (https-everywhere etc.) they won’t create a secure connection.

OMV doesn’t seem to provide it.

What I did:

Activated: „enable SSL/TLS“ and it requires to name a certificate so...

Created a SSL certificate under system->certificates->SSL;

Back to system->general settings->secure connection: named the just created certificate, save, apply.

Left out „force SSL/TLS“ because I assume that this locked me out last time and I went for a re-install (which was faster);

So tried port 443 (left unchanged) and don’t get a connection. It jumps back to HTTP on port 80

Happy to try to activate the force option again but then... where can I find the config file to reverse this via command line?

nmap returns (amongst others):

...

443/tcp open https

...

Did I miss something?

I think before I try this, I will need to specify a path that is not root-owned.

If I try as "admin@" or "root@" (so I can specify a path that works = / ), I get "please verify your user details.

I probablz cannot use a user from group "users" right now as I haven't allocated a home path for them.

Something for tomorrow, thanks for the idea so far!