Didn't learn anything from fusermount command (I suppose I need to learn what that does ) but disabling the systemd service fixed the problem without rebooting.
Thanks for your patience and help.
Didn't learn anything from fusermount command (I suppose I need to learn what that does ) but disabling the systemd service fixed the problem without rebooting.
Thanks for your patience and help.
OK, next issue:
although when run from the command line
/usr/bin/rclone --log-file=/home/scohen/log/wopa/rclone.log mount wopa: /home/scohen/wopa
succeeds, when run from a systemd service, it fails with the following log messages:
2024/08/08 11:49:35 NOTICE: Config file "/root/.config/rclone/rclone.conf" not found - using defaults
2024/08/08 11:49:35 Failed to create file system for "wopa:": didn't find section in config file
Why does it think it needs to look in the /root directory for the config file?
This is my /etc/systemd/user/wopa.service file
[Unit]
Description= start RClone mount of my wopa directory with Google Drive
User=scohen
[Service]
Type=simple
ExecStart=/usr/bin/rclone --log-file=/home/scohen/log/wopa/rclone.log mount wopa: /home/scohen/wopa
#Restart info
Restart=always
RestartSec=10
[Install]
WantedBy=default.target
Recently added the User=scohen line. It didn't change anything.
What am I missing?
i think User=scohen
should go under [Service]
, not [Unit]
else might try to hardcode the path using
--config=/home/scohen/.config/rclone/rclone.conf
and add --log-level=DEBUG
OK, progress made but still no joy.
[Unit]
Description= starting RClone mount of my wopa directory with Google Drive
[Service]
Type=simple
User=scohen
ExecStart=/usr/bin/rclone --log-file=/home/scohen/log/wopa/rclone.log --log-level=DEBUG mount wopa: /home/scohen/wopa
#Restart info
Restart=always
RestartSec=10
[Install]
WantedBy=default.target
when I start the service I get this in the log
2024/08/08 12:38:09 DEBUG : rclone: Version "v1.67.0" starting with parameters ["/usr/bin/rclone" "--log-file=/home/scohen/log/wopa/rclone.log" "--log-level=DEBUG" "mount" "wopa:" "/home/scohen/wopa"]
2024/08/08 12:38:09 DEBUG : Creating backend with remote "wopa:"
2024/08/08 12:38:09 DEBUG : Using config file from "/home/scohen/.config/rclone/rclone.conf"
2024/08/08 12:38:09 Fatal error: failed to mount FUSE fs: directory already mounted, use --allow-non-empty to mount anyway: /home/scohen/wopa
I thought you said never to use --allow-non-empty above somewhere, so I haven't.
But I stopped the service, disabled it, and now get this:
{scohen@taormina ~}$ systemctl stop wopa
{scohen@taormina ~}$ ls wopa
ls: cannot access 'wopa': Transport endpoint is not connected
{scohen@taormina ~}$ rmdir wopa
rmdir: failed to remove 'wopa': Device or resource busy
{scohen@taormina ~}$ systemctl disable wopa
Removed "/etc/systemd/system/wopa.service".
Removed "/etc/systemd/system/default.target.wants/wopa.service".
{scohen@taormina ~}$ rmdir wopa
rmdir: failed to remove 'wopa': Device or resource busy
{scohen@taormina ~}$ cd wopa
bash: cd: wopa: Transport endpoint is not connected
{scohen@taormina ~}$ ps -ef | grep wopa
scohen 206553 83326 0 12:40 pts/2 00:00:00 grep --color=auto wopa
The mount point directory is again in this weird state that I found earlier. The service is stopped and disabled and I can't do a thing with it.
good about the progress.
as for the joy
i understand the mounting is complicated but now, all your issues are not about rclone.
take some time, read the full docs for rclone mount
command and about fusermount
, as i mentioned above.
your systemd service file is missing ExecStop
which executes fusermount
search the forum, dozens of examples of working service files.
Transport endpoint is not connected
that is a linux error about mounting, not rclone error.
correct
Thanks again. It is good for me to get back into this stuff. I'm a retired geek and I'm sitting around with COVID and have nothing else to do, so it helps me pass the time.
when i got covid, my brain/memory was not top game. systemd would have been too hard and no fun ;wink
rclone = fun
so i would focus on rclone on the command line,
that config and mount command, would not work well.
--vfs-cache-mode
is required.three days in with paxlovid: my brain is okay. Two days ago, maybe not.
Thanks, will look at this.
Also looking at this:
i know about that wiki, a good read, but for sure, i would not base my service on that.
most complex systemd service file i have ever seen for rclone.
and based on forum posts, not sure anybody ever used it.
on top of that.
--checkers
does nothing on a mountWell, I got my service file looking serviceable. I ended up using nothing of the tutorial wiki except the ExecStop value, and it now all works as far as starting and stopping the service is concerned. But it doesn't actually mount the folder.
Service file:
[Unit]
Description= starting RClone mount of my wopa directory with Google Drive
[Service]
Type=notify
User=scohen
ExecStart=/usr/bin/rclone --log-file=/home/scohen/log/wopa/wopa.log --config=/home/scohen/.config/rclone/rclone.conf \
--log-level=DEBUG mount wopa: /home/scohen/wopa
ExecStop=/bin/fusermount -u /home/scohen/wopa
#Restart info
Restart=always
RestartSec=10
[Install]
WantedBy=default.target
There are errors logged when it starts but non fatal ones, apparently. I see change notifications and sometimes rate limit errors (which is weird because there are 2 small files in the directory). But I don't see the files in the mount folder.
On the good side, I can start and stop the service now without incident. Yay!
With the service stopped and disabled, I can run ExecStart command from the command line and there it works. So why won't it work as a service?
Yid!
can you post the top thirty lines of the debug log?
maybe --allow-other
as mentioned, create a client id/serect
It's working now. Launch from service. No errors in log. Hooray! Don't know what I did.
As to why I was having trouble stopping things, if anything is accessing a file in the remote (like an app on my iphone) closing that app made the problem go away.
As for allow other, I (and my gmail email address) will be the only one using this so it doesn't seem necessary.
I may go back and set up those client id things you mentioned. The tutorial video I was watching said it wasn't necessary.
that is not the purpose of --allow-other
anyhoo, glad we got it all working
can you share the link?
Docs say about allow-other:
--allow-other Allow access to other users (not supported on Windows)
Tutorial link: https://www.youtube.com/watch?v=YDF1nBaAptw&t=292s
local users on your ubuntu linux, such as scohen
not gmail users.
that is three years old.
about "Root Folder ID"
can get that from the debug log
DEBUG : Google drive root '': 'root_folder_id = 0IYnsu88uXytUk9PVA' - save this in the config to speed up startup
rclone config redacted gdrive01:
[gdrive01]
type = drive
client_id = XXX
client_secret = XXX
token = XXX
root_folder_id = XXX
Back at it again.
There are no other users on my system that I need worry about, unless perhaps root. But would root be barred from something scohen can do?
Will have a look at client id and secret again.
Is there a more recent tutorial that you would recommend instead?
sorry, no.
what do you plan to do with the mount?
I have two stinkin' files that I need to share among my devices. I need any of the devices to be able to access and change these files and have the changes stick. This is the functionality I get with dropbox - but dropbox only allows 3 devices access. Actually, I have a fourth, a Windows partition on this device, but that blows the dropbox limit. Fortunately I don't use it that much. This device I am on now is the only one running linux, the only one for which there is not a Google Drive Desktop app. I plan on soon acquiring another device, probably linux so I want to stay ahead of the game. This problem was mentioned in that old tutorial.
Rather than pay Dropbox or some other vendor way too much for this service, I thought I would use my rusty geek skills to take control of it.
Hey, working on the client id now.
As far as the https://www.googleapis.com/auth/drive scope in concerned, it seems to me that the https://www.googleapis.com/auth/drive.file scope might be more appropriate and safer in my situation as described above. Is that anything you've tried or recommend?