organize
organize copied to clipboard
Monterey, Organize v2: Google Drive gives [Errno 1] Operation not permitted
Sorry, I missed your request to see my config. Organize is still not working with Google Drive.
Here is my config file after migrating to v2 (slightly modified for privacy):
rules:
# move screenshots into year/month/day folders
- locations:
- /Users/x/Pictures/InstantShot
filters:
- extension:
- jpg
- created
actions:
- move: "/Volumes/Google Drive/My Drive/_x/x/x/x (x)/{created.strftime('%Y')}/{created.strftime('%m')}/{created.strftime('%d')}/"
Simulation is successful, but upon running I get errors like:
- (move) ERROR! unable to create /Volumes/Google Drive/My Drive/_x/x/x/x (x)/2022/01/18 ([Errno 1] Operation
not permitted: '/Volumes/Google Drive/My Drive/_x/x/x/x (x)/2022/01/18')
╭─────────────────────────────── Traceback (most recent call last) ────────────────────────────────╮
│ │
│ /Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/organize/cli.py:86 │
│ in run_local │
│ │
│ 83 │ │ config_dir, config_name = split(config_path) │
│ 84 │ │ config = open_fs(config_dir).readtext(config_name) │
│ 85 │ │ os.chdir(working_dir) │
│ ❱ 86 │ │ core.run(rules=config, simulate=simulate) │
│ 87 │ except NeedsMigrationError as e: │
│ 88 │ │ console.error(e, title="Config needs migration") │
│ 89 │ │ console.warn( │
│ /Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/organize/core.py:3 │
│ 09 in run │
│ │
│ 306 │ console.summary(count) │
│ 307 │ │
│ 308 │ if count["fail"]: │
│ ❱ 309 │ │ raise RuntimeWarning("Some actions failed.") │
│ 310 │
╰──────────────────────────────────────────────────────────────────────────────────────────────────╯
RuntimeWarning: Some actions failed.
Originally posted by @andyylin in https://github.com/tfeldmann/organize/issues/152#issuecomment-1032382637
I'm having an identical error when performing sim (success) and run (error) for the following rule:
- name: "DOWNLOADS {files} {moves image types into IMAGE}"
locations: ~/Downloads
enabled: true
filters:
- extension:
- jpg
- jpeg
- png
- jpeg
- tiff
actions:
- move:
dest: "/Downloads/IMAGE/"
on_conflict: rename_new
rename_template: "{name}_{counter}{extension}"
error:
success 5 / fail 1
╭─────────────────────────────── Traceback (most recent call last) ────────────────────────────────╮
│ │
│ /Users/user/opt/anaconda3/lib/python3.7/site-packages/organize/cli.py:88 in run_local │
│ │
│ 85 │ │ config_dir, config_name = split(config_path) │
│ 86 │ │ config = open_fs(config_dir).readtext(config_name) │
│ 87 │ │ os.chdir(working_dir) │
│ ❱ 88 │ │ core.run(rules=config, simulate=simulate) │
│ 89 │ except NeedsMigrationError as e: │
│ 90 │ │ console.error(e, title="Config needs migration") │
│ 91 │ │ console.warn( │
│ /Users/user/opt/anaconda3/lib/python3.7/site-packages/organize/core.py:329 in run │
│ │
│ 326 │ console.summary(count) │
│ 327 │ │
│ 328 │ if count["fail"]: │
│ ❱ 329 │ │ raise RuntimeWarning("Some actions failed.") │
│ 330 │
╰──────────────────────────────────────────────────────────────────────────────────────────────────╯
RuntimeWarning: Some actions failed.
Google Drive seems to change the file and folder permissions - I guess that might be the problem. I guess it should work when you set the correct permissions - but be careful to not expose your files to the open web (article)
I'm not using GDrive myself so I have little experience with that
Thanks, in my case it's not to do with Google Drive, as it just pertains the /Downloads folder in a MacOS system. It never spit this error in earlier versions. Unfortunately, I can't tell in which version started to give error.
When I ran my first rule on the Downloads folder the system asked me whether I'd like to give access. Maybe you have to add organize to "Full disk access" in the privacy settings?
I didn't get asked. I have added Full Disk Access
and Files and Folders
permissions to organize
. Additionally, I've chmod -R 777 Downloads
, but keeps getting the same error...
Very strange, I suspect it's caused by gatekeeper or sandboxing. My Mac is too old for Monterey, maybe anybody else can help?
Interestingly, I have identical rules like e.g.,
- name: "DOWNLOADS {files} {moves audio types into AUDIO}"
locations: ~/Downloads
enabled: true
filters:
- extension:
- ogg
- mp3
- aiff
- wav
- aac
- flac
- 3gp
- opus
- wma
actions:
- move:
dest: "~/Downloads/AUDIO/"
on_conflict: rename_new
rename_template: "{name}_{counter}{extension}"
and it works without problem... I deleted the IMAGE
folder and created a new one but doesn't work. This is a mystery... will keep studying the problem.
Maybe the log file helps: ~/Library/Logs/organize/organize.log
Thanks.
Here you have what I see on screen for two identical rules targetting IMAGES or AUDIO files:
⚙ DOWNLOADS {files} {moves image types into IMAGE}
/Users/user/Downloads
2G0A9513copia_1.jpg
- (move) ERROR! unable to create /Downloads/IMAGE ([Errno 30] Read-only file system: '/Downloads')
In identical rules targeted at other file types:
⚙ DOWNLOADS {files} {moves audio types into AUDIO}
/Users/user/Downloads
emacs.ogg
- (move) Move to /Users/user/Downloads/AUDIO/emacs.ogg
The log for the error is the following:
2022-02-11 12:46:28,157 - organize.core - ERROR - unable to create /Downloads/IMAGE ([Errno 30] Read-only file system: '/Downloads')
Traceback (most recent call last):
File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/organize/actions/move.py", line 125, in pipeline
dst_fs = open_fs(dst_fs, create=False, writeable=True)
File "/Users/user/.local/lib/python3.7/site-packages/fs/opener/registry.py", line 234, in open_fs
default_protocol=default_protocol,
File "/Users/user/.local/lib/python3.7/site-packages/fs/opener/registry.py", line 186, in open
open_fs = opener.open_fs(fs_url, parse_result, writeable, create, cwd)
File "/Users/user/.local/lib/python3.7/site-packages/fs/opener/osfs.py", line 40, in open_fs
osfs = OSFS(path, create=create)
File "/Users/user/.local/lib/python3.7/site-packages/fs/osfs.py", line 141, in __init__
raise errors.CreateFailed(message)
fs.errors.CreateFailed: root path '/Downloads/IMAGE' does not exist
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/Users/user/.local/lib/python3.7/site-packages/fs/osfs.py", line 133, in __init__
os.makedirs(_root_path, mode=int(create_mode))
File "/Users/user/opt/anaconda3/lib/python3.7/os.py", line 211, in makedirs
makedirs(head, exist_ok=exist_ok)
File "/Users/user/opt/anaconda3/lib/python3.7/os.py", line 221, in makedirs
mkdir(name, mode)
OSError: [Errno 30] Read-only file system: '/Downloads'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/Users/locations/opt/anaconda3/lib/python3.7/site-packages/organize/core.py", line 231, in action_pipeline
updates = action.pipeline(args, simulate=simulate)
File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/organize/actions/move.py", line 128, in pipeline
dst_fs = open_fs(dst_fs, create=True, writeable=True)
File "/Users/user/.local/lib/python3.7/site-packages/fs/opener/registry.py", line 234, in open_fs
default_protocol=default_protocol,
File "/Users/user/.local/lib/python3.7/site-packages/fs/opener/registry.py", line 186, in open
open_fs = opener.open_fs(fs_url, parse_result, writeable, create, cwd)
File "/Users/user/.local/lib/python3.7/site-packages/fs/opener/osfs.py", line 40, in open_fs
osfs = OSFS(path, create=create)
File "/Users/user/.local/lib/python3.7/site-packages/fs/osfs.py", line 136, in __init__
"unable to create {} ({})".format(root_path, error), error
fs.errors.CreateFailed: unable to create /Downloads/IMAGE ([Errno 30] Read-only file system: '/Downloads')
OK, it was a silly coding error of my side:
dest: "/Downloads/IMAGE/"
Should have been
dest: "~/Downloads/IMAGE/"
all along sighs
Sorry to have wasted your time.
Great one 😅 Didn't see it either!
Oops, Google Drive issue is still open.
Google Drive seems to change the file and folder permissions - I guess that might be the problem. I guess it should work when you set the correct permissions - but be careful to not expose your files to the open web (article)
I'm not using GDrive myself so I have little experience with that
Sorry if this is a dumb question as I'm not a coder, but does that mean Google Drive treats folder permissions differently on Monterey than on previous MacOS versions? It was working fine before upgrading to Monterey.
I have no idea. I know Monterey changed quite a bit permission-wise.
This might be related to #332? Could you try again with the latest v3 alpha?
Fixed in v3, which is now released 👍