Permissions problem

On the Pi 4 with xeoma, the directories or folders have been created under /mnt , and I have a line in fstab to mount them. mount -a mounts the said directories.

//192.168.0.22/CCTV/xeoma /mnt/CCTV/xeoma cifs credentials=/home/pi/.smbclient, uid=pi 0 0

Now in xeoma, I am getting this error message:

Archive is not being recorded! Failed to create the directory for the archive (/mnt/CCTV/xeoma)

Back to the Pi4 to check permissions.

pi@raspberrypi:/mnt $ ls -la total 0 drwxr-xr-x 1 root root 60 Oct 26 10:24 . drwxr-xr-x 1 root root 160 Jan 1 1970 .. drwxrwxrwx 1 pi root 60 Oct 26 10:24 CCTV

Then I changed owner, which was as above pi@raspberrypi:/mnt/CCTV $ sudo chgrp pi xeoma pi@raspberrypi:/mnt/CCTV $ ls -la total 0 drwxrwxrwx 1 pi pi 60 Oct 26 10:24 . drwxr-xr-x 1 root root 60 Oct 26 10:24 .. drwxr-xr-x 2 pi root 0 Oct 28 10:30 xeoma pi@raspberrypi:/mnt $ sudo chown pi CCTV pi@raspberrypi:/mnt $ ls -la total 0 drwxr-xr-x 1 root root 60 Oct 26 10:24 . drwxr-xr-x 1 root root 160 Jan 1 1970 .. drwxrwxrwx 1 pi root 60 Oct 26 10:24 CCTV

Then changed group:

pi@raspberrypi:/mnt $ sudo chgrp pi CCTV pi@raspberrypi:/mnt $ ls -la total 0 drwxr-xr-x 1 root root 60 Oct 26 10:24 . drwxr-xr-x 1 root root 160 Jan 1 1970 .. drwxrwxrwx 1 pi pi 60 Oct 26 10:24 CCTV

I then tried the same with the /mnt/CCTV/xeoma directory, but no change when changing the group

pi@raspberrypi:/mnt/CCTV $ sudo chgrp pi xeoma pi@raspberrypi:/mnt/CCTV $ ls -la total 0 drwxrwxrwx 1 pi pi 60 Oct 26 10:24 . drwxr-xr-x 1 root root 60 Oct 26 10:24 .. drwxr-xr-x 2 pi root 0 Oct 28 10:30 xeoma

Still xeoma is complaining about not been able to create the directory.

Have I missed something

Reply to
RobH
Loading thread data ...

Seems odd. Try removing the xeoma directory and making a new one, and then chowning and chgrping it.

Also as a test, try chmodding xeoma to go+w, so the program can create any files and subdirectories without group and owner being important. That will at least check that this is possible, even though the best long-term solution is to sort out group ownership and chmod back to go-w.

What happens if you cd to /mnt/CCTV/xeoma and then "sudo chgrp pi ." - that should have the same effect as being one directory up in /mnt/CCTV and chgrping xeoma... but does it?

Reply to
NY

I can't remove the xeoma directory because it has 2 other directories in it which I also can't remove by doing rm -r directory, even after changing owner and permissions. Group doesn't change

Doing sudo chgrp pi . didn't do anything, nor did sudo chgrp go-w xeoma

There must be some way to delete/remove the said directories. I've only used linux/ubuntu for about 2 years, but didn't have this problem with permissions and removing directies.

Reply to
RobH

Update:

I rebooted the Pi 4, and this time I managed to change both owner and group of both the CCTV and xeoma directories from root to pi.

I've no idea why it took a reboot to sort it out?????

Reply to
RobH

(perhaps unrelated to linux)

I have 'devices' around here w/ 'mystery'/unknown embedded systems - mini-Genies which 'bridge' wirelessly between sat TV reception Genie and TV set and controlled by remote - which sometimes exhibit /strange/ behavior which is most easily resolved by rebooting rather than 'figuring it out'.

I still think the first approach to a mystery should be an attempt to rationally figure it out to correct, but somewhere along the way, throw in a reboot (before 'if all else fails').

--
Mike Easter
Reply to
Mike Easter

I've just had another weird one, the fstab file had revered back to default, and consequently the CCTV/xeoma directory was not mounted.The pictures etc were being sent direct to the pi, and not my NAS server, which they would have been.

I have corrected that now, and hopefully it should be ok.

Due to these silly problems, I have considered ditching the pi4 and go back to my ubuntu desktop, but I'll give it a few more days yet.

Reply to
RobH

Given that you're struggling to get changes to "stick" when there's no rational explanation, and files "reverting to default" [1] -- are you sure your SD card isn't dying?

Just a thought, one of the early symptoms of mine going was a partial refusal to write/update/delete files in the usual way.

I think some of the "write" happened, or got cached, but it wasn't really there on the SD card.

Ultimately a reboot "fixed" it, because the stupid thing died altogether and wouldn't boot any more. SD card rapidly end up "mounted" in /bin.

:(

[1] I've only stumbled onto this otherwise, when certain non-hacker distributions of Linux go round re-writing config files when you're not looking. Coming from a Slackware background, I don't expect auto-thing-wizards to be re-writing my config files, thank you.
--
--------------------------------------+------------------------------------ 
Mike Brown: mjb[-at-]signal11.org.uk  |    http://www.signal11.org.uk
Reply to
Mike

Thanks, but at the moment I don't know if it is dying or not. Also what has happened again is the fact that xeoma can't create the directory , after I sorted the permissions before.

I'm going to ditch the pi4 and go back to ubuntu on a spinning disk. I have a NUC which I have installed ubuntu on a spinning disk in a usb 3 HD caddy. And if that doesn't work out, then it'll be back to the desktop.

Reply to
RobH

Let's pause right there for a moment.

So far, you've (sorta) told us that a) you have a NAS at 192.168.0.22 that uses the CIFS (microsoft network) file system b) you mount a subdirectory of this CIFS file system to a mountpoint on your Raspberry Pi 4 c) you run xeoma (which, apparently, is a client/server security camera recording/viewing application) on your RPi4 d) the server portion of xeoma attempts to create a directory under the CIFS mount point

Do I have it correct so far?

If so, a few questions for you:

1) what rpi userid and groupid does xeoma run under? 2) do these match the uid (and default gid) that you used when mounting the CIFS share? (remember, CIFS has no concept of Linux users and groups; you have to specify your desired values in the Linux mount command, and possibly override the values that your NAS provides/expects)

It would have been helpful to see the permissions of /mnt/CCTV/xeoma rather than just /mnt/CCTV.

OK, ownership is as I would have expected it to be from the CIFS mount options (you specified owning user of pi and defaulted the owning group to root). Your chgrp isn't going to do any good; the group owner is specified by the mount options, and (like all other CIFS permissions and ownership information) is not changable through chown/chgrp.

OK, so you can change ownership of a directory /above/ the mountpoint. I don't see the reason for your action here; it contributes nothing to the ownership of the directory (and it's subdirectories) in question.

Yes. Make certain that your mount options and your xeoma process agree on userid and groupid.

--
Lew Pitcher 
"In Skills, We Trust"
Reply to
Lew Pitcher

The rpi userid and groupid are both 1000(pi) Xeoma Owner and Group are both pi.

So both the pi and xeoma agree do they?

Thanks

Reply to
RobH

Remember that CIFS permissions as far as the NAS server is concerned are granted by the server on the basis of whatever you logged in as.

Not by whoever you think you are locally.

--
Socialism is the philosophy of failure, the creed of ignorance and the  
gospel of envy. 
 Click to see the full signature
Reply to
The Natural Philosopher

Further Update:

Due to the continuing problems I had with xeoma and the pi 4, I re flashed the new 64Gb card with buster. I then created the mount point, the mount line in fstab as before, changed permissions as required on the mounted folders, and finally installed xeoma again. This time it runs with no problems and no can't access (mnt/CCTV/xeoma) messages. Pictures and video is now being directed to my NAS machine and are viewable. Phew, at last!

Maybe I went about it the wrong way before, as I initially forgot what I had to do, and then did it after xeoma was running. Anyway all is good now.

Reply to
RobH

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.