Posts by NAS-i-Goreng

So you are suggesting to use the temporary crontab file instead of just using a blank one and save it under /etc/crontab?

I'm familiar with crontab files and I love their flexibility and options. It's more than the GUI provides

Kind of became a command line guy now...

It only leaves the question of where the existing (and functioning) cron job from the GUI went.

If I make another crontab file, I may end up running a job twice (or not at all if there's a clash). So could go and delete the one from the GUI.

Hm, thanks for the manz ideas.

I'm currently testing Mplayer for this, see how this goes then go further maybe.

Regarding cron:

crontab -l returned:

_{no crontab for USER1}

crontab -e says:

_{no crontab for USER - using an empty one}

_{touch: cannot touch '/home/USER1/.selected_editor': Permission denied}

_{Unable to create directory /home/USER1/.local/share/nano/: No such file or directory}

_{It is required for saving/loading search history or cursor positions.}

_{Press Enter to continue}

If I press enter, it opens an editable crontab file but under the path:

_{/tmp/crontab.eWTaUC/crontab}

...so nothing permanent apparently.

So I checked the permissions. Maybe the directory was created and owned by root and chowned /home/USER1 to USER1:USER1.

Now the output of crontab -e is:

_{no crontab for USER1 - using an empty one}

...with the path /tmp/crontab.dDQ4nl/crontab

nano crontab just opens a blank page (which I am tempted to fill and save under /etc/crontab ...should I?).

The solution... was different than what I expected.

Since this is a terminal issue and otherwise didn’t cause any problems, I took a look into the GUI and the user setup again.

The default path for a shell login is bin/sh.

I changed it to usr/bin/bash and et voila, it works.

There’s actually no need to create a home directory as it seems.

df - h does not show any home directories for any of the users.

Ok, so I can just make up a directory and call it /home and all will be well?

In that case...nothing easier than that.

...correction:

I was logged on as root, so changed to the user level.

/etc/cron.d/openmediavault-userdefined does have a cron job listed with a coded reference which refers to an entry in /var/lib/openmediavault/cron.d where the shell command is spelled out.

Both contain the warning that each will be overwritten by the system, so no editing.

Where would I edit cron jobs (apart from the GUI)?

One thing I like about editing the crontab directly is that one can set a specific time, a date and there are just some more options than the GUI provides.

Hm, I might try to delete and re-create the user.

I have one more user and when I log on under this other user, the same issue comes up however.

Quote from gderf

Look in the file /etc/cron.d/openmediavault-userdefined

Look at the files in /var/lib/openmediavault/cron.d

Both are empty.

But for some reason, the scheduled rsync job seems to work now.

For future planning: Where would I write another scheduled job into?

I'm planning to store a video stream from a CCTV for 24hrs, so was planning to rip the video stream and restart the service every 24hrs to overwrite the previous one.

Quote

Use the GUI whenever it is possible.

Hmm, it's still playing up with the secure https connection on an ordinary Firefox. So I often go back to the command line...

Quote

OMV does not mount filesystems automatically (with the exception of the usb backup plugin)

Thanks for this clarification. I can work with that then.

Will check the plugin, but as I entered the stick into the FSTAB , it should happily mount to the same place again as long as I use the same UUID/device.

Hello,

When I log on to OMV via command line as a user (no root permissions), I get the error message

"Could not chdir to home directory /home/username: No such file or directory"

Errr what?!? I specified a home directory in the GUI!

So why does it come up with this?

Quote from 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.

Quote from 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.